Tool to shift all BPMN elements on grid points

[CatalinaMoisuc]

Context

Transferred from:https://github.com/camunda/web-modeler/issues/7202.
cc @till-stadtler

Describe the problem that you are trying to solve

When reviewing and redesigning BPMN models from customers, I invest some time into improving the aesthetics of the BPMN process to make it easier to focus on other aspects.

I spend a significant amount of time at the beginning and throughout the remodeling process to shift BPMN elements on grid points, including resizing pools and subprocesses so their corners lie on grid points.

Describe the solution you'd like to see implemented

I would like to have a tool (a button) to automatically shift all BPMN elements on grid points, including the corners of all pools and subprocesses (and dividing lines of lanes). I suggest to shift every BPMN element that does not lie on a grid point the the next upper-left grid point, to shift every upper-left corner of a pool/subprocess to the next upper-left grid point, and every lower-right corner of a pool/subprocess to the next lower-right grid point.

Describe alternatives you've considered

Spend more time rearranging BPMN elements and pools/subprocesses.

[nikku]

@till-stadtler Thanks for opening this issue.

To better understand your use-case: Why are diagrams this out of order in the first place? I'd assume that snapping already happens during diagram creation:

If you ask me I'd rather ensure that diagrams are snapped (aligned on grid points as you call it) automatically, instead of relying on a tool to batch-do it.

[till-stadtler]

Hi @nikku,

I think it is a good idea to look at why diagrams are out of order!

There are a few reasons:

1. When opening a new BPMN file (Web or Desktop Modeler), the start event is not aligned on the grid points. (at least for me)

<bpmndi:BPMNShape id="_BPMNShape_StartEvent_2" bpmnElement="StartEvent_1">
        <dc:Bounds x="179" y="159" width="36" height="36" />
      </bpmndi:BPMNShape>

(bounds.x + height/2) has to be divisible by 10, for example 182. Same for (bounds.y + width/2).
If you start modeling from there, you are off the grid.

2. When moving elements, they like to be aligned with the center of other elements, including subprocesses. Any subprocess can have a height or width that is not divisible by 20 which would be necessary for the midpoints of its sides to be on the grid. Thus, in about 50% of cases, the alignment with the center of a subprocess causes a misalignment off the grid.

3. Placing a task on the grid an then expanding it to a subprocess, causes its left and right sides to be off the grid.
   

4. The alignment tools in the multi-selection context pad can cause elements to move off the grid. I don't know how often these alignment tools are used, so I can't say if this is an important aspect.

5. Misalignment is contagious. A misaligned element somewhere on the canvas can make it difficult to shift elements onto the grid. Especially, if many elements in a line are off the grid, I have to shift them quite a bit away from their original position, to properly place them on the grid.
   
   
   Thus, I often have to pick up every other item in a process model, shift it a few grid spaces away from its original position and "build the process from scratch" on the grid.

There might be more reasons.

Fixes for each issue:

1. Place the default start event on the grid: k*10 - 18 for any integer k. Probably something like 182/182.
2. Don't align with the center of subprocesses if they are off the grid.
3. Make sure that a subprocess that is created from a task is properly placed on the grid.
4. When performing the distributions, placement on grid takes precedence over the equal distribution (?)
5. Similar to 2. Don't align with the center of an element (not only subprocesses) if they are off the grid.

[nikku]

@till-stadtler Thanks for getting back to us. Let's work towards getting these rocks off your track, instead of developing a magic monkey-patch tool.