Community
Participate
Working Groups
Created attachment 239133 [details] File showing the layout problem with a large number of nodes I want Zest to layout my figures whilst it can assume it has an unlimited amount of space available for this layout. Currently the layouts (e.g. radial, see screenshot) tries to put everything in the available window. Is this solvable in some way?
I am not sure, but maybe Graph#setPreferredSize() might work (have not tested it). If not, the only thing that comes to my mind is to apply a HorizontalShift algorithm after your main algorithm has finished (do something as follows): layout = new CompositeLayoutAlgorithm(new LayoutAlgorithm[]{ new RadialLayoutAlgorithm(), new HorizontalShift() } This will first execute your selected algorithm, then it executes a horizontal shifting that moves nodes horizontally not to overlap with each other. Again, this is not a solution but a workaround (that might cause more issues than it solves). If the first solution does not work, I will try to find something, but that will need some time.
(In reply to Zoltan Ujhelyi from comment #1) > I am not sure, but maybe Graph#setPreferredSize() might work (have not > tested it). I just tried this. It does indeed use that preferred size but then it uses all of it. So if I set it to a pessimistic size (e.g. 100000x100000) then it uses this complete area. So that is not going to work because I have no idea what the reasonable size would be for any given graph. I can imagine some trial and error situation where I query the graph for overlapping nodes and then use some algorithm to increment the size. Is there a way to query for overlapping nodes? > > If not, the only thing that comes to my mind is to apply a HorizontalShift > algorithm after your main algorithm has finished (do something as follows): > > layout = new CompositeLayoutAlgorithm(new LayoutAlgorithm[]{ > new RadialLayoutAlgorithm(), > new HorizontalShift() > } I just tried this as well. Im sorry to say that it does not yield a graph that resembles radial in any way. > > This will first execute your selected algorithm, then it executes a > horizontal shifting that moves nodes horizontally not to overlap with each > other. Again, this is not a solution but a workaround (that might cause more > issues than it solves). > > If the first solution does not work, I will try to find something, but that > will need some time.
(In reply to Zoltan Ujhelyi from comment #1) > If the first solution does not work, I will try to find something, but that > will need some time. The layout needs to calculate the maximum radii (plural of radius) that will fit all elements given their size for a specific node. Then these circles must be fitted in such a way that they don't overlap. It is quite a challenge. Maybe some smart guy (m/f) already did this.
