y.layout
Interface Layouter

All Known Subinterfaces:

LayoutStage

All Known Implementing Classes:

AbstractLabelingAlgorithm, AbstractLayoutStage, ARTreeLayouter, BalloonLayouter, BendConverter, BufferedLayouter, BusRouter, CanonicMultiStageLayouter, ChannelEdgeRouter, ChannelEdgeRouter.OrthogonalShortestPathPathFinder, CircularLayouter, ClearAreaLayouter, CollinearBendHider, CompactOrthogonalLayouter, ComponentLayouter, CompositeLayouter, CompositeLayoutStage, CurveFittingLayoutStage, CurveRoutingStage, DirectedOrthogonalLayouter, EdgeBundlingStage, EdgeGroupRouterStage, EdgeReversalStage, EdgeRouter, FamilyTreeLayouter, FillAreaLayouter, FixedGroupLayoutStage, FixNodeLayoutStage, GenericPartitionGridStage, GenericTreeLayouter, GivenCoordinatesStage, GraphLayoutLineWrapper, GraphTransformer, GraphZoomer, GreedyMISLabeling, GRIP, GroupedShuffleLayouter, GroupNodeHider, GroupNodeRouterStage, HandleNaNCoordinatesStage, HierarchicGroupLayouter, HierarchicLayouter, HierarchicLayouter, HVTreeLayouter, IncrementalHierarchicLayouter, InteractiveOrganicLayouter, IsolatedGroupComponentLayouter, KeepStrongPortConstraintsStage, LabelLayoutDataRefinement, LabelLayoutTranslator, LayoutMultiplexer, MinNodeSizeStage, MISLabelingAlgorithm, MultiPageLayouter, NormalizingGraphElementOrderStage, OrganicEdgeRouter, OrganicLayouter, OrganicPartitionGridLayoutStage, OrganicRemoveOverlapsStage, OrientationLayouter, OrthogonalEdgeRouter, OrthogonalGroupLayouter, OrthogonalLayouter, OrthogonalPatternEdgeRouter, OrthogonalSegmentDistributionStage, ParallelEdgeLayouter, ParentEdgeAugmentationStage, PartialLayouter, PartialLayouter.StraightLineEdgeRouter, PartitionGridLayoutStage, PartitionGridRouterStage, PartitionLayouter, PatchRouterStage, PlaceNodesAtBarycenterStage, PolylineLayoutStage, PortCalculator, PortCandidateAssignmentStage, PortConstraintEnforcementStage, RadialLayouter, RandomLayouter, RecursiveGroupLayouter, ReducedSphereOfActionStage, RemoveColinearBendsStage, RemoveOverlapsLayoutStage, SALabeling, SelfLoopLayouter, SequentialLayouter, SeriesParallelLayouter, ShuffleLayouter, SingleCycleLayouter, SmartOrganicLayouter, SnapOuterPortsToNodeBorderStage, SplitEdgeLayoutStage, StraightLineEdgeRouter, SubgraphLayouter, TabularLayouter, TemporaryGroupNodeInsertionStage, TopLevelGroupToSwimlaneStage, TreeComponentLayouter, TreeLayouter, TreeMapLayouter, TreeReductionStage

public interface Layouter

Layouter describes the general interface for algorithms that perform a layout process on a LayoutGraph.

The main method for invoking the layout calculation is doLayout(LayoutGraph). Implementing classes will arrange the graph there. To avoid that the layout algorithm crashes if it cannot handle the input graph, canLayout(LayoutGraph) can be called to check whether or not a graph is a valid input for the layout algorithm.

This class also provides keys to register DataProviders with the graph that contain information about the nodes and edges in the graph. DataProviders registered with NODE_ID_DPKEY and EDGE_ID_DPKEY contain unique identifiers for both nodes and edges. These identifiers allow for ensuring consistent results even if the order of nodes and edges was changed between two layout runs.
The selection state of nodes and edges is stored in DataProviders registered with the keys SELECTED_NODES and SELECTED_EDGES. Based on this information, the layout algorithm may reduce its calculations to the selected subset of nodes or edges.

Field Summary

static java.lang.Object	EDGE_ID_DPKEY A DataProvider key for looking up a unique identifier for each edge in a graph Layout algorithms may use this information to provide consistent layouts for multiple runs.
static java.lang.Object	NODE_ID_DPKEY A DataProvider key for looking up a unique identifier for each node in a graph Layout algorithms may use this information to provide consistent layouts for multiple runs.
static java.lang.Object	NODE_TYPE_DPKEY A DataProvider key for specifying the type of the nodes in the graph Nodes mapped to equal objects are considered to be of the same type.
static java.lang.Object	SELECTED_EDGES A DataProvider key for looking up the selected state of the edges in the graph A layout algorithm can retrieve a DataProvider registered with this key to apply a special handling to the selected edges.
static java.lang.Object	SELECTED_NODES A DataProvider key for looking up the selected state of the nodes in the graph A layout algorithm can retrieve a DataProvider registered with this key to apply a special handling to the selected nodes.

Method Summary

boolean	canLayout(LayoutGraph graph) Checks whether or not the given graph can be arranged by this layout algorithm.
void	doLayout(LayoutGraph graph) Main layout routine that assigns new layout information to the given graph.

Field Detail

NODE_ID_DPKEY

static final java.lang.Object NODE_ID_DPKEY

A DataProvider key for looking up a unique identifier for each node in a graph

Layout algorithms may use this information to provide consistent layouts for multiple runs.

EDGE_ID_DPKEY

static final java.lang.Object EDGE_ID_DPKEY

A DataProvider key for looking up a unique identifier for each edge in a graph

Layout algorithms may use this information to provide consistent layouts for multiple runs.

SELECTED_NODES

static final java.lang.Object SELECTED_NODES

A DataProvider key for looking up the selected state of the nodes in the graph

A layout algorithm can retrieve a DataProvider registered with this key to apply a special handling to the selected nodes. For example, the layout algorithm may restrict its scope, i.e., it only arranges the selected nodes.

However, it is often more convenient to use a specific DataProvider key for this purpose, e.g., if you want to combine two layout algorithms of the same kind which have to operate on different subsets of the graph. Thus, these algorithms may provide a method like setSubgraphNodesDpKey(Object) that customizes the DataProvider key allowing to specify different sets of selected nodes for nested layout algorithms.

SELECTED_EDGES

static final java.lang.Object SELECTED_EDGES

A DataProvider key for looking up the selected state of the edges in the graph

A layout algorithm can retrieve a DataProvider registered with this key to apply a special handling to the selected edges. For example, the layout algorithm may restrict its scope, i.e., it only routes the selected edges.

However, it is often more convenient to use a specific DataProvider key for this purpose, e.g., if you want to combine two layout algorithms of the same kind which have to operate on different subsets of the graph. Thus, these algorithms may provide a method like setSubgraphEdgesDpKey(Object) that customizes the DataProvider key allowing to specify different sets of selected edges for nested layout algorithms.

NODE_TYPE_DPKEY

static final java.lang.Object NODE_TYPE_DPKEY

A DataProvider key for specifying the type of the nodes in the graph

Nodes mapped to equal objects are considered to be of the same type. Node types can influence a layout algorithm such that, for example, nodes of the same type are preferably placed closer to each other or that only nodes with the same type are allowed to form a special substructure. They are not obeyed by all layout algorithms.

The type is generally treated as a secondary optimization criterion. This means that nodes of the same type are not always simply clustered together. If an algorithm allows to do something like this via other constraints, then it should be done that way. The type instead is used in cases where some free choice is available after considering other constraints.

• The IncrementalHierarchicLayouter uses the types of the nodes as a subordinate criterion during the sequencing of nodes within their layer. It prefers to place nodes of the same type next to each other if this does not induce additional crossings or conflicts with other constraints (like node groups, swimlanes, or sequence constraints). The algorithm uses an additional local optimization heuristic to improve the placement with respect to node types and, thus, does not guarantee optimal results. Furthermore, this additional step may increase the required runtime. Note that node types do not affect the layer assignment.
• In the organic layout and in the orthogonal layout, the node type affects the detection of substructures (e.g. star structures, cycles, chains). If types are defined, each substructure either consists of nodes that all have the same type or only of nodes without type. For parallel and star structures, the organic layout furthermore offers to turn off this strict separation, with the effect that types are still considered, but only within a structure to, e.g., improve the ordering of nodes.
• The GenericTreeLayouter and TreeLayouter classes use the types of the nodes as a criterion for sorting the child nodes of a local root node such that nodes of the same type are placed consecutively, if possible. The primary criterion is still given by the GenericTreeLayouter.getDefaultChildComparator() and the TreeLayouter.getComparator() respectively.
• For the SingleCycleLayouter class, there is a custom node type aware sequencer implementation. It can be specified via SingleCycleLayouter.setNodeSequencer(y.algo.NodeSequencer) and ensures that the nodes are sorted according to their type. Note that this implementation can also be used for the CircularLayouter if the partition layout style is set to CircularLayouter.PARTITION_LAYOUTSTYLE_CYCLIC. The instance of the single cycle layout can be obtained with method CircularLayouter.getSingleCycleLayouter()).
• The ComponentLayouter takes types into consideration when arranging components. If all nodes of a component have the same node type, the component is considered to be of that type. Components with same type are preferably put next to each other. The arrangement styles most suitable for node types are ComponentLayouter.STYLE_ROWS, ComponentLayouter.STYLE_SINGLE_ROW, ComponentLayouter.STYLE_SINGLE_COLUMN and ComponentLayouter.STYLE_MULTI_ROWS_TYPE_SEPARATED. Other styles aim at other optimization criteria such that it is not guaranteed that components of same type are put close to each other.

Node types are not considered by all layout algorithms and they are only treated as a weak and optional optimization criterion. If there are other constraints (e.g. group nodes), they are prioritized.

See Also:

SmartOrganicLayouter.setParallelSubstructureStyle(byte), SmartOrganicLayouter.setStarSubstructureStyle(byte), SmartOrganicLayouter.setCycleSubstructureStyle(byte), SmartOrganicLayouter.setChainSubstructureStyle(byte), SmartOrganicLayouter.setParallelSubstructureTypeSeparationEnabled(boolean), SmartOrganicLayouter.setStarSubstructureTypeSeparationEnabled(boolean), OrthogonalLayouter.setTreeStyle(byte), OrthogonalLayouter.setCycleStyle(byte), OrthogonalLayouter.setChainStyle(byte)

Sample Graphs:

Hierarchic Layout without considering types

Hierarchic Layout considering types

Organic Layout without considering types

Organic Layout considering types

Tree Layout without considering types

Tree Layout considering types

Method Detail

canLayout

boolean canLayout(LayoutGraph graph)

Checks whether or not the given graph can be arranged by this layout algorithm. Calling the main layout routine on this graph will only succeed if this method returns true.

Parameters:

graph - the input graph

Returns:

true if this layout algorithm can handle the input graph, false otherwise

See Also:

doLayout(LayoutGraph)

doLayout

void doLayout(LayoutGraph graph)

Main layout routine that assigns new layout information to the given graph. The call to this routine will only succeed if the layout algorithm can handle the input graph.

Parameters:

graph - the input graph

See Also:

canLayout(LayoutGraph)