DAGView

Discussion about the development of the Assembly workbench.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: DAGView

Post by Fat-Zer »

tanderson69 wrote:You can see in the post migration that the group features contain multiple links to the same feature. I don't think that is an acceptable state for group features. fix that, and I think the exception and the dagview assert will go away.
yes, you are right... I thought DocumentObjectGroup will handle it correctly... at least it won't result in totally broken structure... I'll try to fix both the group object and my migration code...

PS: Thanks for debugging that and sorry for bothering you with such stuff...
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: DAGView

Post by tanderson69 »

Fat-Zer wrote:PS: Thanks for debugging that and sorry for bothering you with such stuff...
No problem. On a related note: Situations like this, is why I have fallen in love with 'assert' over the last year.
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: DAGView

Post by Fat-Zer »

Just wondering about future use cases... Is the DAGView a general implementation and may display arbitrary graph Data? or at least arbitrary set of ViewProviders/DocumentObjects? or is it nailed to display App::Document content?
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: DAGView

Post by tanderson69 »

Fat-Zer wrote:Just wondering about future use cases... Is the DAGView a general implementation and may display arbitrary graph Data? or at least arbitrary set of ViewProviders/DocumentObjects? or is it nailed to display App::Document content?
No, Its pretty rigid in it's present form. What are you thinking about doing?
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: DAGView

Post by Fat-Zer »

tanderson69 wrote:
Fat-Zer wrote:Just wondering about future use cases... Is the DAGView a general implementation and may display arbitrary graph Data? or at least arbitrary set of ViewProviders/DocumentObjects? or is it nailed to display App::Document content?
No, Its pretty rigid in it's present form. What are you thinking about doing?
I was thinking about a Body content reordering form with a draggable DAG view... Also I had thoughts about a DAG of Documents in multi-document workflow... But anyway neither of them is coming soon, just some fantasies of the bright future =))

By the word, is it would be hard to make the DAG View respect [as much as possible ofc.] the order of elements returned by the ViewProviders' claimChildren()?
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: DAGView

Post by tanderson69 »

Fat-Zer wrote:I was thinking about a Body content reordering form with a draggable DAG view
Yes I also have had thoughts of reordering by dragging. Eventually I think we could do it in the current view and forget about an extra form/dialog.
Fat-Zer wrote:Also I had thoughts about a DAG of Documents in multi-document workflow...
Yeah another good use case. I looked around and I couldn't find any abstract framework for a DAG view.
Fat-Zer wrote:By the word, is it would be hard to make the DAG View respect [as much as possible ofc.] the order of elements returned by the ViewProviders' claimChildren()?
Order is a big one and has been touched upon a couple of times on this thread.

Right now order is totally dependent on boosts topological_sort routine and I feel that should be the last operation. Meaning, I don't think we should try to do any post topo-sort ordering. The best way would be a sorted container for graph edges with a custom predicate. Not sure exactly what this predicate would involve, but I don't think claimChildren is the answer. IMHO claimChildren feels like an adaptor from a DAG to a tree and that is something we shouldn't need and should stay specific to the tree.

I think if you change the order of features in the vector returned by DocumentObject::getOutList(), you can control the order of children in the DAG view. This might be a good temporary solution.
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: DAGView

Post by Fat-Zer »

tanderson69 wrote: I think if you change the order of features in the vector returned by DocumentObject::getOutList(), you can control the order of children in the DAG view. This might be a good temporary solution.
Hmm... this one doesn't feel right... Firstly, it's not a virtual and IMHO it's not intended to be, because it's a generic algorithm... secondly, the order is needed only for display purposes, so IMHO we shouldn't put it into the App implementation...
tanderson69 wrote:but I don't think claimChildren is the answer. IMHO claimChildren feels like an adaptor from a DAG to a tree and that is something we shouldn't need and should stay specific to the tree.
Yes, it were, but I think about it more as some sort of "Stronger bound", which should be respected first... may be even it will makes sense to draw it's lines in the DAG half of pixel wider...
My idea is to build a "tree-like" DAG based on claimChildren() first, and toposort it, then use the output as a hint for the complete toposort.
tanderson69 wrote:Right now order is totally dependent on boosts topological_sort routine and I feel that should be the last operation.
looked through it... there is no way to affect the output order but guessing input in some smart way... IMHO we will have to implement our own "static" topo sort (surely with blackjack and hookers as people say), which will take some hints of the desired order...

But unfortunately I don't yet see an algorithm of such sort...
User avatar
tanderson69
Veteran
Posts: 1626
Joined: Thu Feb 18, 2010 1:07 am

Re: DAGView

Post by tanderson69 »

Fat-Zer wrote:
tanderson69 wrote: I think if you change the order of features in the vector returned by DocumentObject::getOutList(), you can control the order of children in the DAG view. This might be a good temporary solution.
Hmm... this one doesn't feel right... Firstly, it's not a virtual and IMHO it's not intended to be, because it's a generic algorithm... secondly, the order is needed only for display purposes, so IMHO we shouldn't put it into the App implementation...
never claimed it was right :D In addition I didn't say what I meant. I meant, you would have to control the order of the property link additions when creating the feature. This should control the order out of DocumentObject::getOutList(). Doesn't matter I am not going to fight for it.

Fat-Zer wrote:
tanderson69 wrote:but I don't think claimChildren is the answer. IMHO claimChildren feels like an adaptor from a DAG to a tree and that is something we shouldn't need and should stay specific to the tree.
Yes, it were, but I think about it more as some sort of "Stronger bound", which should be respected first... may be even it will makes sense to draw it's lines in the DAG half of pixel wider...
My idea is to build a "tree-like" DAG based on claimChildren() first, and toposort it, then use the output as a hint for the complete toposort.
I started out using claim children. Every feature can do(lie) whatever it wants and is way too tightly coupled to the treeview. Trying to merge the output of claimChildren into the topo sorted list sounds convoluted to me. I still think meta data, as I described in the first post, inside feature and link properties is the way to go. This data can be useful outside just gui cues.
viewtopic.php?f=20&t=11276#p90705
viewtopic.php?f=20&t=11276&start=10#p90915
viewtopic.php?f=20&t=11276&start=50#p95274

Fat-Zer wrote:
tanderson69 wrote:Right now order is totally dependent on boosts topological_sort routine and I feel that should be the last operation.
looked through it... there is no way to affect the output order but guessing input in some smart way... IMHO we will have to implement our own "static" topo sort (surely with blackjack and hookers as people say), which will take some hints of the desired order...

But unfortunately I don't yet see an algorithm of such sort...
sorted containers on the vertices and edges or a custom DFS.
Post Reply