DAGView

Discussion about the development of the Assembly workbench.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: DAGView

Post by DeepSOIC »

BaseApp/Preferences/DAGView as evident from commit message.
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: DAGView

Post by triplus »

Fat-Zer wrote:
tanderson69 wrote:
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...
Afterwards, you have to restart freecad, then you should have a menu option to turn it on. It has most of the basic functionality.
there is or what is that «parameter»? I can't find too...
Tools -> Edit parameters ... -> BaseApp -> Preferences -> DAGView (Enabled true)

And after FreeCAD restart:

View -> Views -> DAG View
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: DAGView

Post by Fat-Zer »

triplus, thanks.

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
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).
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: DAGView

Post by triplus »

adding visible isolation on right click
Works good. As for the whole show/hide support in DAGView i think this is overall big improvement compared to current tree view.
highlight connectors
Fantastic. This makes DAGView much more useful and easy to use and navigate!

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".
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).
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: DAGView

Post by tanderson69 »

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.
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:Too much text color and i wonder if the graph colors would suffice and the text should be in single color?
I want more than one persons feedback.
triplus wrote:Inserting new Part indents connections for new Part. Is there special reason this happens?
Minor glitch should be an easy fix.
triplus wrote:Top-down graph would probably feel more natural to me.
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:And probably Part, Origin, MainBody objects first and after the rest.
"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: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".
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: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).
Come up with a procedure to reproduce the problem and create a new forum thread or a mantis ticket.
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: DAGView

Post by DeepSOIC »

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.
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.

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.
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: DAGView

Post by jriegel »

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....
Stop whining - start coding!
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: DAGView

Post by tanderson69 »

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.
Alright we have enough different opinions that I will try to make this an option and default to top down.

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....
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.
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: DAGView

Post by triplus »

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?
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.
I want more than one persons feedback.
I agree.
Please stop repeating yourself.
Point taken. I will try but can't promise anything.
"first after the rest" what does that even mean?
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!
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.
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.
Come up with a procedure to reproduce the problem and create a new forum thread or a mantis ticket.
Fair enough.
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: DAGView

Post by tanderson69 »

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.
The default selection mode of the dag view is single. I am guessing you changed the selectionMode parameter and forgot about it?
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!
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: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.
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.
Post Reply