-
Notifications
You must be signed in to change notification settings - Fork 0
Diagram dialect
Basic idea is that there are lot of defaults as in VID and position is automatically incremented and adjusted with across, below, rear, above, return, retreat, next, pad, at, to-left, to-right, up, down, cw, ccw, in, out and compass directions. Main layouts beside VID-flow (rows or cols) model include strict grid (tabular), circular and radial. This does not require infinite scrolling or something - it is dialect to describe easily diagrams, with ability to define new (also compound and parametrized) styles. Base dialect should not be semantical but stay as geometrical as possible, BUT -- here comes in the power of DG -- we can build grammars for upper-lever semantical dialects, e.g. data-diagrams, sequence diagrams, flowcharts, statecharts, DRAKON, BPMN, UML, whatever... as long as we are able to formulate (meta)grammar for it that translates higher-level dialect into our VID-like base diagram dialect, that the diagram rendering engine translates into Draw proper and renders live.
Diagram dialect has three levels: layout, group and shape. Shapes are by default given predefined dimensions and default shape is box. Shapes are gathered into space-separated sequenced groups with default orientation and alignment. Default orientation is to-right and default alignment is middle and center. Four boxy groups are across, below, rear (is this better than reverse?) and above. They differ only by default initial orientation. Inside each group orientation can be changed by direction keywords to-right, down, to-left and up. Both groups and shapes can be placed at absolute positions (relative to layout and group correspondingly) with at keyword and relatively to current position with pad. New groups are started also with return and retreat. return works similarly as in VID, returning to-right or below the start of last group, retreat returns (i.e. retreats) to the opposite side, i.e. before or above the last group and starts a new group with same default orientation as previous group. next starts also new group, but on position where next shape would have been positioned. If offset of new elements/groups becomes negative, they are not adjusted but layout's offset is corrected accordingly, so that entire layout adjusts its position dynamically without need to adjust positions of every element and group when moving out of visible in negative side, nor to calculate positions beforehand.
There are also cascade, circular and radial groups. cascade is generalized boxy group, where shapes are positioned in many compass directions, e.g. NE, NNE, ENE etc. (boxy across, below, rear and above corresponding to cascade E, S, W and N correspondingly). For circular and radial groups there are cw/ccw and in/out directions instead of to-left/to-right and up/down directions as in boxy groups. For circular the main direction is, well, circular, and secondary - radial; for radial vice versa. In addition they need radius and start angle to be defined. Similar to space separating shapes in boxy groups, sweep angle and radius differences are used to position shapes in round groups.
Shapes can contain nested layouts with different defaults, laid out by same rules and determining the size of parent shape (like panels in VID).
Shapes in group will be connected in order of sequence after connected keyword is used or connect keyword appears between two shapes. Flow can be splitted into several threads and joined together again as required. Splitted parts form separate layout that is treated as single element as considers positioning and alignment but without parent shape. First elements of each splitted thread is connected by default to last common element (if any - i.e. groups can start with splitted head) and last element of each thread is connected to first common element after split, much like alternatives in railroad diagram, but with lot more placement and styling options.
Connections run from borders to borders of shapes, otherwise it will be hard to find them proper placement in draw-block -- in flat layout it would not be problem, just insert connectors before shapes and connect centers of shapes; but with nested layouts this is not applicable as parent boxes will not let to connect children of different nestings. So universal solution is probably to start connectors on borders and not bother about order of elements in draw-block, although this makes finding of each point where-on-border to place the end of connector more complicated. Also, arrowheads need to be placed on borders anyway. Connectors are straight lines, orthogonal lines, splines, snake-lines as in railroad, arcs and curves too. Shapes are reused as arrowheads. Line styles can vary colors, thickness, dash and dot patterns. Connector-labels are still not implemented, but should be placeable/align-able/rotate-able on different parts of connectors and style-able similarly to shape-labels.
grid determines the cell size of grid layout, where shapes are placed relative to grid-cells, i.e. with constant distances, not depending on shapes sizes. Layout ideas are similar as for boxy groups with some quirks.