Ticket #4224 - hard crash with App::Link

[realthunder]

...
2) the representation of the dependencies was so confusing that it didn't actually make any sense: ...

I think the DAG view takes a while to get used to, but I assume it is implemented correctly. So, more than changing it radically, it requires more documentation to explain to the user what the lines mean. As I understand it, it is similar to how a Git repository with all its branches can be displayed.

I think the DAG view does need some improvement to be useful, especially when assemblies are involved. See the following screenshot of an assembly with only 4 levels of hierarchies. Actually, it's not about hierarchies. DAG view becomes less useful when there are many children at any hierarchy. I think we shouldn't directly copy the git branching view here. It will be better to make the branching indicator show on demand. Maybe show only the involved branches of the selected object.

Screenshot from 2019-12-15 07-14-03.png (42.55 KiB) Viewed 511 times

3) I think that App::Link itself could be used in much better way to do exactly what the DAG view wanted to do. I'll write about it in another thread, but the short idea would be to have a sequential tree view, where all functions follow each other in the sequence of their creation...

I was thinking about history view as well, but for a different need. The problem with FC's tree view is that the tree hierarchy has two different meanings, which causes confusion. For a geo group (App::Part), the hierarchy represents a coordinate system. For other objects (fusion, extrusion, etc.), the hierarchy indicates dependency. One of my recent effort is to make the tree hierarchy show only as coordinate system, so that when an extrusion is moved, and the user selects the sketch claimed by the extrusion, he will find the sketch following the extrusion, which will make editing a lot easier.

This of course will create various problems, one of which is that the sketch can be reused, and the user needs a way to select the sketch in its original coordinate system. This is where a history view will be handy, because the objects inside will always be shown in its original coordinate system. We can have a history view for the entire document, and separate views of objects inside an App::Part. Maybe make the view a sub panel beside the tree, and can be shown/hidden on demand. I've seen something like that in other CAD.

[vocx]

I think the DAG view does need some improvement to be useful, especially when assemblies are involved. See the following screenshot of an assembly with only 4 levels of hierarchies. Actually, it's not about hierarchies. DAG view becomes less useful when there are many children at any hierarchy. I think we shouldn't directly copy the git branching view here. It will be better to make the branching indicator show on demand. Maybe show only the involved branches of the selected object.

You are right. It could definitely be improved. Obviously, when the DAG view was implemented App::Link didn't exist and the developers couldn't anticipate all use cases, particularly with assemblies. It was developed to be somewhat useful in small models but no doubt it could be improved to handle more complex cases.

See the threads where it was presented.
*DAGView
*easter egg of PartDesign Next: DAG View

... The problem with FC's tree view is that the tree hierarchy has two different meanings, which causes confusion. For a geo group (App::Part), the hierarchy represents a coordinate system. For other objects (fusion, extrusion, etc.), the hierarchy indicates dependency.

Correct. This is the issue, the current tree view shows the history of the model but also the relationships. It's not strictly a historical list, but also not a strictly dependency graph. It's a mix of both. I think for the most part it works okay in an intuitive way with simple models, but it does presents some issues when you start using the same object in different places.

... We can have a history view for the entire document, and separate views of objects inside an App::Part. Maybe make the view a sub panel beside the tree, and can be shown/hidden on demand. I've seen something like that in other CAD.

Yes, if you could implement a different view, that is strictly historical, maybe that is also useful in many cases. I think having more of these tools is beneficial to see what works best.

[tanderson69]

ping

ping

FYI: If I remember correctly: The dagview layout engine is setup for filters. I just never made any other than for testing. I really don't do anything with freecad anymore, so I won't be working on it.

[chrisb]

I just never made any other than for testing. I really don't do anything with freecad anymore, so I won't be working on it.

Sad to hear; many thanks for your great contributions!