ComponentArrangementStyle

The strategy tries to arrange the components such that the aspect ratio of the final component placement gets as close as possible to the aspect ratio of the preferred layout size, configurable using preferredSize.

In contrast to ROWS, each row may also be divided into further sub-rows, which is especially useful if there are few very large components and many significantly smaller ones.

The strategy tries to arrange the components such that the aspect ratio of the final component placement gets close to the aspect ratio of the preferred layout size, configurable using preferredSize. But in contrast to MULTI_ROWS, this strategy does not always try to come as close to the preferred view ratio, if a ratio close to the preferred ratio only induces a lot of unused view space. This unused space will be minimized.

In contrast to ROWS, each row may also be divided into further sub-rows, which is especially useful if there are few very large components and many significantly smaller ones.

The resulting height does not exceed the preferred height ( preferredSize).

In contrast to MULTI_ROWS_HEIGHT_CONSTRAINT_COMPACT, the result will be an arrangement which uses as much height as possible, even if that means that all components will be arranged in one single column.

The resulting height does not exceed the preferred height ( preferredSize).

In comparison with MULTI_ROWS_HEIGHT_CONSTRAINT, the result will be compacted, which means that an arrangement with the minimum width such that the height constraint is still fulfilled will be realized.

The strategy for placing components of the same type is equal to that of MULTI_ROWS, but components of different node types are not placed in the same nested row. This means rows are not filled up anymore (even though there would be space), but the components of different types are placed in a new row. Therefore, this strategy produces more rows and is less compact.

The type of a component is derived from the type of its nodes such that if most of the nodes are of the same type, the component is considered to be of this dominant type, too. If there is no dominant type, the component is considered to have no type. Components without a type are separated from the components with a type.

In contrast to MULTI_ROWS without type separation, this strategy may not come as close to the preferred view ratio, because the node types are of higher priority. Furthermore, results may contain more white space and be less compact.

The resulting width does not exceed the preferred width ( preferredSize).

In contrast to MULTI_ROWS_WIDTH_CONSTRAINT_COMPACT, the result will be an arrangement which uses as much space in width as possible, even if that means that all components will be arranged in a single row.

The resulting width does not exceed the preferred width ( preferredSize).

In comparison with MULTI_ROWS_HEIGHT_CONSTRAINT the result will be compacted, in order to minimize unused view space induced by components that are large in height.

Entities of different components will not overlap, however the bounds of the components may overlap.

In contrast to PACKED_CIRCLE, components might even be placed in empty spaces inside other components.

Entities of different components will not overlap, however the bounds of the components may overlap.

In contrast to PACKED_RECTANGLE, components might even be placed in empty spaces inside other components.

The aspect ratio of the rectangle is defined by the preferredSize of the graph.

Entities of different components will not overlap, however the bounds of the components may overlap.

The aspect ratio of the rectangle is defined by the preferredSize of the graph.