Community
Participate
Working Groups
The steps field in DirectedGraphLayout is restricted to package level access. I would like to remove one of steps from the algorithm, but I can't access the list of steps (and this time i don't see an accessor method :)
If you had access, how could you remove a step in a way that is likely to break?
It is not great, but I override the visit method and I remove the step I want (this.steps.remove(10)). Also if GraphVisitor was public I could add new steps. Ideally all the steps would be public so I could change these, etc... but that might be too much of an API breaking change, and that's why I didn't want to request that.
calling remove(10) is not going to be very resistant to future changes. How about starting with what you are trying to achieve. Do you want to provide your own local optimize step?
No it's not very resistant to future changes. I was just trying to do something that wound't cause too many problems for Draw2D either. Basically the horizontal placement is taking a lot of time (10 seconds on my graph) and I found a naive solution can do the job is less than 100ms. (As well, the min cross routine can take some time and it isn't always needed). So for my case I just wanted to remove this and run my horizontal placement afterwards. But the more I think about this, what if we made the GraphVisitor public so anyone could extend the DirectedGraphLayout and provide their own visit routine. This way I could also write a visitor that takes a progress monitor and updates its steps after each operation. This requires a few changes to the Visit steps since the visit / revisit methods are set to package visibility. I just wanted to find a good balance between a solution and not changing Draw2D too much.
> I just wanted to find a good balance between a solution and not changing Draw2D > too much. The problem is not changing the API too much. It's maintaining it once it has been changed (or in this case committed). HorizontalPlacement is definitely slow because it "converges" on the answer. It could be made faster by rewriting it, or maybe throwing in some randomness early on to make it converge sooner. I think it's better to try to fix the problem rather than commit to API that few clients would actuall use. If you have a faster solution, maybe it could be contributed and enabled using some key-value settings on the layout.
> > HorizontalPlacement is definitely slow because it "converges" on the answer. It > could be made faster by rewriting it, or maybe throwing in some randomness > early on to make it converge sooner. I think it's better to try to fix the > problem rather than commit to API that few clients would actuall use. If you > have a faster solution, maybe it could be contributed and enabled using some > key-value settings on the layout. > I would be happy to contribute mine. Mine just takes each node in the level and spaces them out. It doesn't worry about the horizontal ordering of the nodes. For large, highly connected graphs, this is much faster. However, it doesn't produce as good a result. (Although with a large, highly connected graph, I'm not sure there is always a good result). What about changing the GraphVisitor to public. If you didn't want to make all the steps public, I could create (and contribute) a factory that would create them. This way, a new Layout algorithm could be built by instantiating the required steps and applying them however the developer sees fit (or adding their own). It would also allow someone to create the layout that takes a progress listener, and manage it accordingly. Another example would be a radial step, that when run afterwards would take a tree and spiral it out from the center.
*** Bug 325947 has been marked as a duplicate of this bug. ***
