This class is typically used by higher-level widgets to implement layout on their behalf. It is intended to wrap an element (usually a <div>), and lay its children out in a predictable fashion, automatically accounting for changes to the parent's size, and for all elements' margins, borders, and padding.
To use this class, create a container element (again, usually a <div>) and pass it to {@link #Layout(Element)}. Rather than attaching child elements directly to the element managed by this {@link Layout}, use the {@link Layout#attachChild(Element)} method. This will attach the childelement and return a {@link Layout.Layer} object which is used to manage thechild.
A separate {@link Layout.Layer} instance is associated with each childelement. There is a set of methods available on this class to manipulate the child element's position and size. In order for changes to a layer to take effect, you must finally call one of {@link #layout()} or{@link #layout(int)}. This allows many changes to different layers to be applied efficiently, and to be animated.
On most browsers, this is implemented using absolute positioning. It also contains extra logic to make IE6 work properly.
NOTE: This class will only work in standards mode, which requires that the HTML page in which it is run have an explicit <!DOCTYPE> declaration.
NOTE: This class is still very new, and its interface may change without warning. Use at your own risk.
@author danyelf @author tom nelson
Layout interface to allow the LayoutController to run it properly. See the LayoutBuilder documentation to know how layout should be instanciated.
To have fully integrated properties that can be changed in real-time by users, properly define the various LayoutProperty returned by the {@link #getProperties()} method and provide getter and setter for each.
@author Helder Suzuki
The layout algorithm role is to compute the best possible positions of nodes in a given space (2D or 3D) and eventually break points for edges if supported using either aesthetic constraints, hierarchical constraints or grouping constraints. As there are many such algorithms with distinct qualities and uses, this interface defines what is awaited from a general layout algorithm.
This algorithm is a {@link Pipe} that receives notifications on the grapheventually maintain an internal representation of it (or for some of them work directly on the graph), and in return send graph events to give each node a position via "xyz" attributes. Some algorithms may also export more information for nodes and edges. For example some algorithms are also able to work on the shape of an edge or the shape of a node.
The layout algorithm described by this interface may be iterative. Some algorithm will compute directly their final representation of the graph in one pass. However most algorithms will probably work step by step until a global quality function is satisfied. This is the best way to handle evolving graphs.
This behavior has been chosen because this algorithm is often run aside the main thread that works on the graph. We want a thread to be able to compute a new layout on its side, without disturbing the main algorithm run on the graph. See the {@link org.graphstream.ui.layout.LayoutRunner} for an helperclass allowing to create such a thread.
To be notified of the layout changes dynamically, you must register as a sink of the layout.
The graph viewers in the UI package often use a layout algorithm to present graphs on screen.
@since 20050706 | |
| |
| |
| |
| |
| |
| |
| |
| |
| |