DAGView
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: DAGView
BaseApp/Preferences/DAGView as evident from commit message.
Re: DAGView
Tools -> Edit parameters ... -> BaseApp -> Preferences -> DAGView (Enabled true)Fat-Zer wrote:there is or what is that «parameter»? I can't find too...tanderson69 wrote:Afterwards, you have to restart freecad, then you should have a menu option to turn it on. It has most of the basic functionality.tanderson69 wrote:...The viewer has to be enabled through a parameter(off by default) so you can totally shut it off if problems become an annoyance...
And after FreeCAD restart:
View -> Views -> DAG View
Re: DAGView
triplus, thanks.
Found a failed assertion:
Steps to reproduce:
1. Clear selection in any way.
2. Double click anywhere in the DAGView (doesn't matter if it's a feature or an empty space).
Found a failed assertion:
Code: Select all
Program received signal SIGABRT, Aborted.
0x00007fffeefa4e07 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007fffeefa4e07 in raise () from /lib64/libc.so.6
#1 0x00007fffeefa616a in abort () from /lib64/libc.so.6
#2 0x00007fffeef9e006 in __assert_fail_base () from /lib64/libc.so.6
#3 0x00007fffeef9e0b2 in __assert_fail () from /lib64/libc.so.6
#4 0x00007ffff75149f3 in Gui::DAG::Model::mouseDoubleClickEvent (this=0x22db700, event=0x7fffffffb340) at /home/alexander/projects/free-cad_code/src/Gui/DAGView/DAGModel.cpp:915
#5 0x00007ffff24908f0 in QGraphicsScene::event(QEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#6 0x00007ffff1ea336c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#7 0x00007ffff1ea9add in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#8 0x00007ffff737a3f5 in Gui::GUIApplication::notify (this=0x7fffffffc550, receiver=0x22db700, event=0x7fffffffb340) at /home/alexander/projects/free-cad_code/src/Gui/Application.cpp:1563
#9 0x00007ffff13e82dd in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/qt4/libQtCore.so.4
#10 0x00007ffff24a7037 in QGraphicsView::mouseDoubleClickEvent(QMouseEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#11 0x00007ffff1ef3ade in QWidget::event(QEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#12 0x00007ffff22967de in QFrame::event(QEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#13 0x00007ffff24a8089 in QGraphicsView::viewportEvent(QEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#14 0x00007ffff13e8454 in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () from /usr/lib64/qt4/libQtCore.so.4
#15 0x00007ffff1ea334c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#16 0x00007ffff1ea9c1a in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#17 0x00007ffff737a3f5 in Gui::GUIApplication::notify (this=0x7fffffffc550, receiver=0xb25160, event=0x7fffffffba60) at /home/alexander/projects/free-cad_code/src/Gui/Application.cpp:1563
#18 0x00007ffff13e82dd in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/qt4/libQtCore.so.4
#19 0x00007ffff1ea93f3 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) () from /usr/lib64/qt4/libQtGui.so.4
#20 0x00007ffff1f1bd4b in ?? () from /usr/lib64/qt4/libQtGui.so.4
#21 0x00007ffff1f1a79c in QApplication::x11ProcessEvent(_XEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#22 0x00007ffff1f418f2 in ?? () from /usr/lib64/qt4/libQtGui.so.4
#23 0x00007fffea6a7754 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#24 0x00007fffea6a7998 in ?? () from /usr/lib64/libglib-2.0.so.0
#25 0x00007fffea6a7a3c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#26 0x00007ffff14159ae in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#27 0x00007ffff1f419a6 in ?? () from /usr/lib64/qt4/libQtGui.so.4
#28 0x00007ffff13e6e7f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#29 0x00007ffff13e7175 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#30 0x00007ffff13ec5c9 in QCoreApplication::exec() () from /usr/lib64/qt4/libQtCore.so.4
#31 0x00007ffff7375d1d in Gui::Application::runApplication () at /home/alexander/projects/free-cad_code/src/Gui/Application.cpp:1837
#32 0x000000000040bbf8 in main (argc=1, argv=0x7fffffffcee8) at /home/alexander/projects/free-cad_code/src/Main/MainGui.cpp:328
(gdb) f 4
#4 0x00007ffff75149f3 in Gui::DAG::Model::mouseDoubleClickEvent (this=0x22db700, event=0x7fffffffb340) at /home/alexander/projects/free-cad_code/src/Gui/DAGView/DAGModel.cpp:915
915 assert(selections.size() == 1);
(gdb) p selections
$21 = std::vector of length 0, capacity 0
1. Clear selection in any way.
2. Double click anywhere in the DAGView (doesn't matter if it's a feature or an empty space).
Re: DAGView
Works good. As for the whole show/hide support in DAGView i think this is overall big improvement compared to current tree view.adding visible isolation on right click
Fantastic. This makes DAGView much more useful and easy to use and navigate!highlight connectors
I wonder if holding down CTRL key to get into multi select mode for connection highlighting should be used instead? The reason is simple. To avoid double clicking when quickly moving and selecting between objects to show relations. Therefore to do the job in single instead of double click.
Some additional notes as i see them ATM:
- Too much text color and i wonder if the graph colors would suffice and the text should be in single color?
- Inserting new Part indents connections for new Part. Is there special reason this happens?
- Top-down graph would probably feel more natural to me. And probably Part, Origin, MainBody objects first and after the rest.
- Is there a way to set connection color to "none"? If that is possible i was thinking it would be nice to have possibility to set that on individual object or especially on objects like MainBody. Regardless of the setting connection highlighting should still work the same when selecting object with connection color set to "none".
- tanderson69
- Veteran
- Posts: 1626
- Joined: Thu Feb 18, 2010 1:07 am
Re: DAGView
So you don't want any connector highlight unless more than one item is selected and when more than one is selected the connector highlight should try to follow all the connectors between the selected features?triplus wrote:I wonder if holding down CTRL key to get into multi select mode for connection highlighting should be used instead? The reason is simple. To avoid double clicking when quickly moving and selecting between objects to show relations. Therefore to do the job in single instead of double click.
I want more than one persons feedback.triplus wrote:Too much text color and i wonder if the graph colors would suffice and the text should be in single color?
Minor glitch should be an easy fix.triplus wrote:Inserting new Part indents connections for new Part. Is there special reason this happens?
You have already mentioned top down. You mentioned connector highlight on more than one occasion. Please stop repeating yourself. The git dag viewers go from bottom to top. The freecad dependency viewer goes from the bottom to top. I want more than just one persons input before I change something.triplus wrote:Top-down graph would probably feel more natural to me.
"first after the rest" what does that even mean? I am guessing you mean that the parents are on the left side of the graph and the children are on the right. This is also inconsistent with the git dag viewers I have seen. I think you are trying to conform this to the tree view. Again more peoples input.triplus wrote:And probably Part, Origin, MainBody objects first and after the rest.
I don't think we need user control of the individual colors. We can just set all the text black if the color coordination between the nodes and the text are not useful.triplus wrote:Is there a way to set connection color to "none"? If that is possible i was thinking it would be nice to have possibility to set that on individual object or especially on objects like MainBody. Regardless of the setting connection highlighting should still work the same when selecting object with connection color set to "none".
Come up with a procedure to reproduce the problem and create a new forum thread or a mantis ticket.triplus wrote:P.S. On unrelated note in new Part Design it's quite easy to get to "The graph must be a DAG" warning message (and FreeCAD crash after).
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: DAGView
In the tree view, the latest objects are at the bottom. Yes, in graph view they are typically at the top. This is the source of inconsistency, IMO.tanderson69 wrote:The git dag viewers go from bottom to top. The freecad dependency viewer goes from the bottom to top. I want more than just one persons input before I change something.
It is natural (IMO) to use latest objects most often, so having them at the top is a good idea (less scrolling). Otherwise, I don't care.
Re: DAGView
I took a look at the DAG view.
Here my 2 cent.
Looks really nice! Gives a good overview about complicated DAGs.
I'm also a top down guy. In western civilization its always top to down and left to right. All CAD systems work that way also Word/Excel and Explorer. Breaking that habit will raise some eyebrows... I know, git do it the other way around, but thats not a common background.
On my hight DPI Laptop display its nearly unusable (very tiny) cause it don't obey to the system % settings for the display. The Qt views (Tree/Table) do that automatically. I think you have to think about it from the start, otherwise it gets really hard later....
Here my 2 cent.
Looks really nice! Gives a good overview about complicated DAGs.
I'm also a top down guy. In western civilization its always top to down and left to right. All CAD systems work that way also Word/Excel and Explorer. Breaking that habit will raise some eyebrows... I know, git do it the other way around, but thats not a common background.
On my hight DPI Laptop display its nearly unusable (very tiny) cause it don't obey to the system % settings for the display. The Qt views (Tree/Table) do that automatically. I think you have to think about it from the start, otherwise it gets really hard later....
Stop whining - start coding!
- tanderson69
- Veteran
- Posts: 1626
- Joined: Thu Feb 18, 2010 1:07 am
Re: DAGView
Alright we have enough different opinions that I will try to make this an option and default to top down.jriegel wrote:I'm also a top down guy. In western civilization its always top to down and left to right. All CAD systems work that way also Word/Excel and Explorer. Breaking that habit will raise some eyebrows... I know, git do it the other way around, but thats not a common background.
I am generating all layout parameters from the default app font. Does the text in the dag view look noticeably smaller than the text in the tree view? I will look into this. Thanks for the feedback.jriegel wrote:On my hight DPI Laptop display its nearly unusable (very tiny) cause it don't obey to the system % settings for the display. The Qt views (Tree/Table) do that automatically. I think you have to think about it from the start, otherwise it gets really hard later....
Re: DAGView
ATM if i click on any object in DAGView it will select it and do the connection highlighting. That is how it should and does work.tanderson69 wrote:So you don't want any connector highlight unless more than one item is selected and when more than one is selected the connector highlight should try to follow all the connectors between the selected features?
What happens next is what i wanted to discuss. If another object in DAGView is clicked connection highlighting will be again activated for that second object BUT first object will still be selected with connection highlighting set to ON. Therefore to just get connection highlighting for the second object you have to click again on the first object selected to de-select it.
Therefore what i actually suggested was clicking on the second object should automatically de-select first object unless CTRL key is pressed.
I asked myself what will users do more often. Will they want to check individual object relations or will they want to select more objects at the same time to see all the relations. I could be wrong by my conclusion was individual object relations will be used more often as selecting more objects at the same time to see all the relations makes it much harder to decrypt the highlighted connections.
I agree.I want more than one persons feedback.
Point taken. I will try but can't promise anything.Please stop repeating yourself.
Currently it works like "sandwich". As soon as user inserts new Part "two slices" are there. On top Part + MainBody and at the bottom Origin + Planes. User starts to put objects between them. Suggestion was to have everything at the top from the start but yes that only makes sense if top-down graph should be used. I mentioned it again!"first after the rest" what does that even mean?
Actually the suggestion was not about setting the color but about removing it. Show/hide connections. The rationale behind it is for example MainBody is "connected to everything" in that body and if user could hide connections for MainBody a lot of "bloat" could be removed temporarily.I don't think we need user control of the individual colors. We can just set all the text black if the color coordination between the nodes and the text are not useful.
Fair enough.Come up with a procedure to reproduce the problem and create a new forum thread or a mantis ticket.
- tanderson69
- Veteran
- Posts: 1626
- Joined: Thu Feb 18, 2010 1:07 am
Re: DAGView
The default selection mode of the dag view is single. I am guessing you changed the selectionMode parameter and forgot about it?triplus wrote:ATM if i click on any object in DAGView it will select it and do the connection highlighting. That is how it should and does work.
What happens next is what i wanted to discuss. If another object in DAGView is clicked connection highlighting will be again activated for that second object BUT first object will still be selected with connection highlighting set to ON. Therefore to just get connection highlighting for the second object you have to click again on the first object selected to de-select it.
Therefore what i actually suggested was clicking on the second object should automatically de-select first object unless CTRL key is pressed.
I asked myself what will users do more often. Will they want to check individual object relations or will they want to select more objects at the same time to see all the relations. I could be wrong by my conclusion was individual object relations will be used more often as selecting more objects at the same time to see all the relations makes it much harder to decrypt the highlighted connections.
This is known. I actually thought of this ahead of time and the very first post of this thread touches on this subject. There are several things to consider in order to try and get a view that changes as you would expect. I have decided to try and build concessis among the community that the dagview is a good way forward before I spend a lot of time on this difficult problem.triplus wrote:Currently it works like "sandwich". As soon as user inserts new Part "two slices" are there. On top Part + MainBody and at the bottom Origin + Planes. User starts to put objects between them. Suggestion was to have everything at the top from the start but yes that only makes sense if top-down graph should be used. I mentioned it again!
Just because english is my native tongue doesn't mean I understand it. I know what you mean, the partdesign::body feature is busy because it has a connector to every feature. At some point each object type might have some control over how it is rendered in the dag view, but that is for later. Right now I am working on the idea of filters, where features can be hidden. Of course connectors that connect to a hidden feature will be hidden also. I am cautious about walking down this road as I don't like stuff hidden from me.triplus wrote:Actually the suggestion was not about setting the color but about removing it. Show/hide connections. The rationale behind it is for example MainBody is "connected to everything" in that body and if user could hide connections for MainBody a lot of "bloat" could be removed temporarily.