DAGView

[tanderson69]

I have roughed in a new viewer for displaying a DAG. It is on our merge "assembly branch" for now and I plan on large atomic commits so we can pull it off later if need be. The viewer has to be enabled through a parameter(off by default) so you can totally shut it off if problems become an annoyance. There is no real functionality through the viewer yet. There are a lot of little things to do, but the biggest problem is with the layout engine. I have 2 very simplistic versions, one using Gui::ViewProviderDocumentObject::claimChildren and the other just looking at App::DocumentObject::Outlist. I don't think either one is specific enough to create a good looking graph. I am thinking of tagging(virtual methods) features(App::DocumentObject) with "create" or "modify" (maybe more). These would signify whether to continue a branch or create a new one. Alternatively, maybe these could be in the propertylink* objects with branching descriptions like: "create", "continue" and "terminate".
For example:
"create" features: primitives(box, cylinder etc..), datums(plane points etc.), sketch.
"modify" features: fillet, chamfer, booleans, pad, pocket,
My design document can help explain some of this. It is in the source folder.
Thoughts?


Here are a couple of teaser visuals.

DagView2_simple.png (27.16 KiB) Viewed 3421 times

DagView1_complex.png (76.65 KiB) Viewed 3421 times

[triplus]

Looks good.

• Would it be possible to hover/select individual connection line and to highlight it?
• Are the points images or "coded"?
• Would it make sense and would it be possible to have indentation of tree objects not aligned vertically but to flow with the graph?

[tanderson69]

Would it be possible to hover/select individual connection line and to highlight it?

What is the point of selecting a connection line?

Are the points images or "coded"

The points are QGraphicsEllipseItems. Why do you ask?

Would it make sense and would it be possible to have indentation of tree objects not aligned vertically but to flow with the graph?

What does "flow with the graph" mean? More like the current dependency viewer?

[triplus]

What is the point of selecting a connection line?

Imagine you would like to find the connection and you would need to scroll the tree view. Or for Tree View to have much connections like in your second example (or more). Or both. It would be in my opinion quite convenient to be able to highlight the connection.

The points are QGraphicsEllipseItems. Why do you ask?

Not a big issue but they do look a bit pixelated. Reading this turning on anti-aliasing painting hint for ellipse items could be used to overcome that?

What does "flow with the graph" mean? More like the current dependency viewer?

I attached sample images from here.

Currently tree objects are vertically aligned:



This is what i was thinking for indentation to flow with the graph.



This way user would only need to scroll tree view horizontally in parts of the tree view where there are a lot of connection lines.

[tanderson69]

What is the point of selecting a connection line?

Imagine you would like to find the connection and you would need to scroll the tree view. Or for Tree View to have much connections like in your second example (or more). Or both. It would be in my opinion quite convenient to be able to highlight the connection.

Ok, you don't want to necessarily select the connector, but instead have the connector visibly reflect the selection of an associated feature. That is something I have thought about but haven't done anything toward it.

This is what i was thinking for indentation to flow with the graph.

Ok. If that is something we feel we need it can be done after a fully functional control. I would like to experience the need for it, before we add unnecessary complications.

[triplus]

Ok, you don't want to necessarily select the connector, but instead have the connector visibly reflect the selection of an associated feature. That is something I have thought about but haven't done anything toward it.

Yes that would work. It would probably be easier to select tree object this way and do the connection highlighting automatically (from the user and the coder perspective).

Ok. If that is something we feel we need it can be done after a fully functional control. I would like to experience the need for it, before we add unnecessary complications.

I agree. Maybe others don't feel the same and would like to have vertically aligned tree objects in the end. In simple tree/graph use cases this probably works a bit better (vertical align). The rationale to make indents follow the graph is to be able to do most of the work by not scrolling horizontally when graph is visible. And in medium to complex tree/graph use cases this approach might work a bit better.

As for my final observation (but this is totally subjective and it's more about the polish) using slightly wider lines and applying some color on it wouldn't hurt. Few additional examples from the above link:

Two color combination where highlighted connection stands out and the colors themselves are easy on the eyes:



Probably slightly to wide lines therefore somewhere in between current implementation and this sample would do just fine.

[triplus]

I tried to imagine from your two examples on how would i be actually using it myself if it would already be available in FreeCAD. Two conclusions that might be wrong as i didn't actually use it but just made assumptions on how it would work.

• If indentation would flow with the graph some users might make wrong assumptions of "feature(s) hierarchy". That is something to take into consideration.
• Two color relation/connection highlighting to determine "feature(s) hierarchy" might be quite powerful thing to use. One color for "relation(s)/connection(s) from" and second color used for "relations(s)/connection(s) to".

As for the whole concept and how the end users will manage it? I am not sure. "FreeCAD Next" will be a bit more powerful for sure compared to "FreeCAD Current" and it does look like a bit steeper learning curve will be involved at least in some areas. Said that "FreeCAD Next" will probably need better tree view management (for example indicating relations/connections between tree objects and spreadsheet) and it does look like this could be appropriate solution trying to solve just that. User will probably need to have deeper understanding and overview of the relations at any time and current tree view does that only up to a point!

[ickby]

Hello tanderson,

I did have a brief look at your dag view. I do like it, I think this kind of view is a nice addition. Not as visually comprehencable as the dependency graph, but way less space hungry. IMHO a good compromise.

One thing I noticed is that it does not work well for "overlapping edges"- Meaning if two parts depend on one, the edges overlap and it becomes basicly impossible to differentiate the paths. For example create a part with some solid, make a datum plane based on that solid and then pad a sketch on top of the datum plane. Now add a second part and create a sketch in this second part on top of the edatum plane of the first part. Now the dag view gets impossible to read correct (can't attach the file right now, sorry)

A second thing imeaditly noticable is the missing possibility for grouping. It would help very much for understanding if one would be able to close groups like in the tree. For example the origins are most likely never of interest. This does of course create a huge problem: once multiple graph nodes are grouped inside one parent, all the subnode edges need to originate from the parent node. To stay in the example, once the origin node is collapsed all edges connecting to the planes and lines no need to be connected to the origin itself. However, as you seem to use the boost graph library I can offer some code that has already solved that problem. The exact same functionality is needed for the assembly solver so I created a set of template classes around boost::graph which do exactly this: subgrouping graphs while keepig the connections. If interested have a look at this:

the explanation of the concept: https://github.com/ickby/openDCM/blob/m ... rgraph.hpp
the base class: https://github.com/ickby/openDCM/blob/m ... sgraph.hpp
the cluster graph: https://github.com/ickby/openDCM/blob/m ... rgraph.hpp
a filter graph: https://github.com/ickby/openDCM/blob/m ... rgraph.hpp

if you have any questions feel free to ask. It may be also helpful to build the project documentation, as then nice pictures are included into the clustergraph documentation.

[triplus]

Yes i noticed the lack of groups yesterday and how collapsing a group should therefore just point all the connections to that group instead. How manageable would that be with lots of connections i am not sure. Maybe to solve that potential issue we should intentionally make overlapping connections for connections to/from group object? That might make sense with external geometry connections between two tree objects where only one (overlapping) connection would be shown for more efficient space management. As for overlapping connections. Probably proper connection highlighting mechanism could in a way solve that issue.

I had one additional thought today. It would be nice to have "fine control" over connections visible in the graph. For example spreadsheet connections, external geometry connections, feature connections... To be able to toggle the visibility of this individual groups of connections.

[tanderson69]

Hello tanderson,

I did have a brief look at your dag view. I do like it, I think this kind of view is a nice addition. Not as visually comprehencable as the dependency graph, but way less space hungry. IMHO a good compromise.

Hello, I was hoping you would chime in as we have had a similar conversation a little while ago.

One thing I noticed is that it does not work well for "overlapping edges"- Meaning if two parts depend on one, the edges overlap and it becomes basicly impossible to differentiate the paths. For example create a part with some solid, make a datum plane based on that solid and then pad a sketch on top of the datum plane. Now add a second part and create a sketch in this second part on top of the edatum plane of the first part. Now the dag view gets impossible to read correct (can't attach the file right now, sorry)

I don't really follow your example as it trying to use a datum plane from another body/part which part design rejects. Doesn't matter though because I have no doubt the problem you describe exists. My question to you about this is: Does this problem exist because a feature node/point isn't in the correct column? If the answer is yes, this leads back to the point of my original post.

A second thing imeaditly noticable is the missing possibility for grouping. It would help very much for understanding if one would be able to close groups like in the tree. For example the origins are most likely never of interest.

I have had some thoughts and I was leaning toward the idea of filters. Mainly to try and stay away from more scene items and animation.
filter ideas:
show paths from "leaf"
show paths from "root"
hide paths under "origin" or whatever object.
show paths for body object.
more
Nothing in this matter is concrete.

This does of course create a huge problem: once multiple graph nodes are grouped inside one parent, all the subnode edges need to originate from the parent node. To stay in the example, once the origin node is collapsed all edges connecting to the planes and lines no need to be connected to the origin itself. However, as you seem to use the boost graph library I can offer some code that has already solved that problem. The exact same functionality is needed for the assembly solver so I created a set of template classes around boost::graph which do exactly this: subgrouping graphs while keepig the connections. If interested have a look at this:

the explanation of the concept: https://github.com/ickby/openDCM/blob/m ... rgraph.hpp
the base class: https://github.com/ickby/openDCM/blob/m ... sgraph.hpp
the cluster graph: https://github.com/ickby/openDCM/blob/m ... rgraph.hpp
a filter graph: https://github.com/ickby/openDCM/blob/m ... rgraph.hpp

if you have any questions feel free to ask. It may be also helpful to build the project documentation, as then nice pictures are included into the clustergraph documentation.

Hah! I already looked at it a little while ago out of curiosity and even made some changes to the documentation. Sounds interesting, but to be honest the idea/concept hasn't penetrated my thick skull yet. Is your latest code merged into jurgens assembly branch? Even though I am building this on the assembly branch I am doing my best to make the dagview independent.