Ticket #4224 - hard crash with App::Link

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
realthunder
Posts: 1591
Joined: Tue Jan 03, 2017 10:55 am

Re: Ticket #4224 - hard crash with App::Link

Postby realthunder » Sat Dec 14, 2019 11:50 pm

vocx wrote:
Sat Dec 14, 2019 10:01 pm
Zolko wrote:
Sat Dec 14, 2019 7:41 pm
...
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
Screenshot from 2019-12-15 07-14-03.png (42.55 KiB) Viewed 197 times

Zolko wrote:
Sat Dec 14, 2019 7:41 pm
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.
Try Assembly3 (latest version 0.11) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
vocx
Posts: 4334
Joined: Thu Oct 18, 2018 9:18 pm

Re: Ticket #4224 - hard crash with App::Link

Postby vocx » Sun Dec 15, 2019 3:37 am

realthunder wrote:
Sat Dec 14, 2019 11:50 pm
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.
Always add the important information to your posts if you need help.
To support the documentation effort, and code development, your donation is appreciated: paypal.
User avatar
tanderson69
Posts: 1536
Joined: Thu Feb 18, 2010 1:07 am

Re: Ticket #4224 - hard crash with App::Link

Postby tanderson69 » Mon Dec 16, 2019 1:59 am

vocx wrote:
Sun Dec 15, 2019 3:37 am
ping
realthunder wrote:
Sat Dec 14, 2019 11:50 pm
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
Posts: 25206
Joined: Tue Mar 17, 2015 9:14 am

Re: Ticket #4224 - hard crash with App::Link

Postby chrisb » Mon Dec 16, 2019 8:55 am

tanderson69 wrote:
Mon Dec 16, 2019 1:59 am
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!