Rank 1
The major reason for our need for a custom layout algorithm is that your algorithms fail for most trees when using custom nodes. It's usually something like 90% correct, but that 10% looks really awful.
More about this issue here:
http://www.telerik.com/community/forums/wpf/diagram/treedown-layout-not-working-for-custom-nodes.aspx
This is what we have now:
var layoutSettings = new TreeLayoutSettings() { TreeLayoutType = Telerik.Windows.Diagrams.Core.TreeLayoutType.TreeDown, HorizontalSeparation = 50d, UnderneathVerticalTopOffset = 50d, UnderneathHorizontalOffset = 80d, ComponentsGridWidth = 2000d, UnderneathVerticalSeparation = 100, AnimateTransitions = true }; this.treeLayout.Layout(this.diagram, layoutSettings);Result: See treedown.png.
Wanted: See treedown_extended.png
UPDATE: Why not just give us the source code of TreeLayout.cs. That would help a lot!
8 Answers, 1 is accepted
Rank 1
First we highly encourage you to take advantage of our priority support by sending us a support ticket. This way your 24-hours response time is guaranteed.
The source code of TreeLayout.cs is located in Telerik.Windows.Diagrams.Core solution. You should be able to see it since you have Developer Licence with subscription. However, we don't believe it is a good idea to override some of the methods there to achieve the layout you need.
Based on your feedback from your other threads, we think you need some kind of topological sort. It cannot be implemented out of the box with Tree Layout since it uses tree with single root and has a presumption that every shape has single parent shape and I see from your pictures that this is not your case (the blue shape in the middle has 2 parent shapes).
Looking at the graph in your pictures, have you considered using a TreeUp Layout and set the red shape as a root ? If this is not a solution in bigger graph you can consider this:
- Use TreeDown Layout with single root.
- Implement a method that traverses the shapes with multiple parents. If the parent shape is below it's child, just reposition it, then recursivly chech its parent with the new position you have given. I think this way you will be able to achieve this kind of topological sorting you are looking for without building an entirely new algorithm .
Petar Mladenov
Telerik
Learn what features your users use (or don't use) in your application. Know your audience. Target it better. Develop wisely.
Sign up for Free application insights >>
Rank 1
Are you saying that we should sort our multi-parent shapes before performing a TreeLayout? Would that help the TreeLayout algorithm?
TreeUp is indeed an alternative, but unfortunately it looks like we will have multiple "end nodes" too. I believe we will give this "sort shapes" idea a shot.
No, I mean you first invoke TreeLayout then invoke your method that handles shapes with multiple parents and arranges them. We recently also added DiagramLayoutCompleted event which will fit well in this case - it will give you a moment in which the layout has already passed and every shape has its new position already set. In its event handler you will be able to onvoke the custom method.
Hope this will help you proceed further.
Petar Mladenov
Telerik
Learn what features your users use (or don't use) in your application. Know your audience. Target it better. Develop wisely.
Sign up for Free application insights >>
Rank 1
By the way, when you're saying "just reposition it", do you mean I should calculate its new position or that I should simply swap the positions of the parent and the child?
Yes, I mean calculate new position. Something like:
If my parent is below me, set this parent to position next to the parent that is above me.
Petar Mladenov
Telerik
Learn what features your users use (or don't use) in your application. Know your audience. Target it better. Develop wisely.
Sign up for Free application insights >>
Rank 1
Your suggested solution would probably work, but I do realize that the post-layout step soon becomes quite complex. I'm not sure it would be easier than implementing/modifying the existing TreeLayout algorithm. Here's why I think this solution is too complex:
To detect a layout error, there are two possible conditions to look for:
1) The second (or third, or fourth...) parent node is below the child.
2) The second (or third, or fourth...) parent node is left of the first parent.
#1
Quite easy to fix. We have:
Child C (green in the attached image).
Parent P1 of C (brown in the attached image).
Parent P2 of P1 (blue in the attached image).
P2 and all its parent nodes need to be moved to the left so that P2.Right = P1.Left+(P1.Right-C.Left). Nice. Obviously, there will be other cases. E.g. P1 has no children at all, P1 has several children or P1 has C to the right instead of to the left. The offset will vary a lot, and your layout algorithm already has the necessary logic to calculate the offsets - for single-parent graphs, that is.
#2
See the node marked with a yellow circle. Ehm... yeah, it's just too complicated to do this in a post-layout step.
Conclusion
Either we implement a multi-parent/multi-child (non-cyclic) layout algorithm or you do it. I believe it makes perfect sense to have this in your framework, since at least one of your competitors has this feature. Please let us know if you plan to add this feature or not. If not, would it be possible to get TreeLayout.cs even though we don't have licensed the source code? Maybe I can use my bonus points for that? :)
Thanks
We can add this as feature request in our PITS and we can consider implementing it if it gathers enough votes - this is the usual procedure for such requests.
As for the Source Code of Treelayout.cs you can use JustDecompile.
Petar Mladenov
Telerik
Learn what features your users use (or don't use) in your application. Know your audience. Target it better. Develop wisely.
Sign up for Free application insights >>