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