LayoutKeys

A layout algorithm can retrieve a IDataProvider 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 IDataProvider 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 IDataProvider key allowing to specify different sets of selected edges for nested layout algorithms.

A layout algorithm can retrieve a IDataProvider 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 IDataProvider 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 IDataProvider key allowing to specify different sets of selected nodes for nested layout algorithms.

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 HierarchicLayout 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 TreeLayout and ClassicTreeLayout 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 defaultOutEdgeComparer and the comparer respectively.
• The BalloonLayout uses the types of nodes in a similar way as the other tree layout algorithms: to sort the child nodes around their root such that nodes of same type are placed consecutively, where possible. If defined, the comparer is stronger than the node type criterion. However, the node types are considered more important than the childOrderingPolicy. In general, the compactness of the results may be lower due to types, since the algorithm has less freedom in sorting the sub-trees - this may be especially noticeable in conjunction with the interleaving feature enabled.
• The RadialLayout uses the types of the nodes as a subordinate criterion for nodes of the same circle. More precisely, for nodes of the same circle (i.e., within the same layer), the algorithm prefers to place nodes of the same type next to each other if this does not induce additional crossings or conflicts with other constraints. Note that 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. The layer assignment is not affected by the node types.
• For the SingleCycleLayout class, there is a custom node type aware sequencer implementation. It can be specified via nodeSequencer and ensures that the nodes are sorted according to their type. Note that this implementation can also be used for the CircularLayout if the partition layout style is set to CYCLE. The instance of the single cycle layout can be obtained with method singleCycleLayout). In addition, the specified node types also influence the layout of the cycle partitions which is done with an instance of the BalloonLayout as well as the detection of star substructures (see starSubstructureStyle for more information).
• The ComponentLayout 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 ROWS, SINGLE_ROW, SINGLE_COLUMN and 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.
• Te CompactDiskLayout takes the types into account instead of the connected components. In particular, nodes of the same type are placed closely together forming a visual component.