Bug 313665 - Some Layout Algorithms Can Place Nodes Outside of Screen Bounds
Summary: Some Layout Algorithms Can Place Nodes Outside of Screen Bounds
Status: NEW
Alias: None
Product: GEF
Classification: Tools
Component: GEF-Legacy Zest (show other bugs)
Version: 3.5.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: gef-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-20 03:57 EDT by Simon CLA
Modified: 2010-05-24 20:21 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon CLA 2010-05-20 03:57:30 EDT
Noticed when using TreeLayoutAlgorithm and RadialLayoutAlgorithm.

This bug is reproducable using the example applications includes in the "Simple Swing Example included with the Zest source:

org.eclipse.zest.layouts.exampleUses.SimpleSwingExample.java

1. Run the application.
2. Click "Radial".
3. Note that the nodes at the bottom of the graph are drawn closer to the
   containers edge than those at the top. The graph is off centre on the Y 
   axis. Also note that this does not occur on the X axis.

Graphs appear shifted down the Y axis. In some cases this shift can cause nodes to be drawn outside of the bounds given to the layout algortihm.

The same shift can be seen when using the TreeLayoutAlgorithm. It is not seen using FlowLayout or GridLayout.

I have traced this problem back to the function AbstractLayoutAlgorithm.adjustNodeSizeAndPos(...) where removing the call in the else {} block to node.setInternalLocation() appears to solve the problem.

Unfortunately I don't know the context behind the logic used in this function so I can't say for sure whether my fix is the best solution, but it seems to work for the cases I have tested so far.

If this is the correct fix I believe the code is also broken for the X axis in cases where widthToHeightRatio is < 1.0. A similar fix should be applied there.
Comment 1 Simon CLA 2010-05-24 20:21:28 EDT
This is really just a workaround. The problem can still occur in some cases.

A proper fix needs to be investigated.

(In reply to comment #0)
> I have traced this problem back to the function
> AbstractLayoutAlgorithm.adjustNodeSizeAndPos(...) where removing the call in
> the else {} block to node.setInternalLocation() appears to solve the problem.