LayoutKeys

This IMapper<K,V> key allows the user to specify hints on the directedness of edges. More precisely, a value of 1 indicates that the is considered to be directed from source to target, a value of -1 that it is directed from target to source, and a value of 0 means that it is undirected.

The directedness of edges is considered e.g. for calculating the hierarchy in the HierarchicalLayout or automatically detecting subcomponents in the OrganicLayout, OrthogonalLayout and CircularLayout.

This key is observed by the following algorithms:

• CircularLayout
• HierarchicalLayout
• LayoutGraphNodeAggregation
• OrganicLayout
• OrthogonalLayout

The padding defines the space between the boundary of a group node and its contents. This padding can be used to reserve space for visual decorations such as labels or borders that should not overlap with the node's children.

Layout algorithms that handle group nodes can use this key to retrieve the padding value during layout calculations.

The minimum size defines the smallest allowable size for a group node. When applied, layout algorithms should ensure that group nodes do not shrink below this size during the layout process.

For group nodes with children, layout algorithms should respect the minimum size to prevent the node from being smaller than its contents or specified constraints.

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 HierarchicalLayout 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 sequenceConstraints ). 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 OrganicLayout and in the OrthogonalLayout, 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 class uses 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 childOrder.
• The RadialTreeLayout 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 childOrder 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 subtrees - 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.
• The CircularLayout automatically orders nodes by their type within the cycle partitions if there is no custom nodeComparator specified, no edges are bundled and fromSketchMode is disabled. In addition, the specified node types also influence the layout of the cycle partitions that is done with an instance of the RadialTreeLayout.
• 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.

Assign true to an edge label if it should be handled by a labeling algorithm, or false otherwise.

This key is observed by the GenericLabeling algorithm.

Assign true to a node label if it should be handled by a labeling algorithm, or false otherwise.

This key is observed by the GenericLabeling algorithm.

Assign true to an edge if it should be handled by an edge routing algorithm, or false otherwise.

This key is observed by the following edge routing algorithms:

• EdgeRouter
• OrganicEdgeRouter
• StraightLineEdgeRouter
• CurveRoutingStage
• CurveFittingStage
• OctilinearRoutingStage

Edges sharing a source edge group identifier will share a common bus near the source or at a common source node if possible.

Assign an identifier which is the same for all edges in one source edge group or null for non-grouped edges.

Edges sharing an alignment identifier will either share the same port location or be placed directly opposite of each other if possible.

Assign an identifier which is the same for all edges in one alignment group or null for non-aligned edges.

Assign an identifier to an edge for specifying the port group at that edges' source or null for edges without port group.

All edges with the same port group id at a node will share the same port location. However, they will be routed independently.

Edges sharing a target edge group identifier will share a common bus near the target or at a common target node if possible.

Assign an identifier which is the same for all edges in one target group or null for non-grouped edges.

Edges sharing an alignment identifier will either share the same port location or be placed directly opposite of each other if possible.

Assign an identifier which is the same for all edges in one alignment group or null for non-aligned edges.

Assign an identifier to an edge for specifying the port group at that edges' target or null for edges without port group.

All edges with the same port group id at a node will share the same port location. However, they will be routed independently.