When resizing a pool/participant with message flows attached to its border, outgoing message flows are attached at a new position and redrawn, while incoming message flows “stick” at their original position. See:
I think the behaviour for outgoing flows should be changed so that they behave just as the incoming flows: all message flows should just stick at the position at which they have been before the resizing operation.
this seems to be a bug with resizing, because it works just fine with moving elements around.
I’ll be adding an issue for this.
The bug concerns outgoing message flows directly attached to participants/pools only. But when you move around such a participant you will see this bug, too: outgoing flows are redrawn, incoming flows stick where they are!
After some fiddling around, there’s actually no bug. The way the algorithm works is that it always keeps the source point and moves the target point if it can draw a straight line (from the unchanged source point).
This is a general concept, which applies both to resizing or moving message flows.
So the desired behavior would be to keep message flows from moving if their source and target points can still remain parallel (can only happen if both elements have some parallel surface) ?
I just played around with participants, sub processes and message flows even more than before and actually tend to see a bigger issue now than before. I believe the algorithm probably is just not adequate. It’s a difficult topic, but I’d give it a shot with an algorithm following those two rules:
Message flow’s source and target points connected to a flow symbol always stick at the border point of the flow symbol at which they have been connected before.
Message flow’s source and target points connected to a participant stay at the x-coordinate of the drawing area as long as it is possible to re-connect the message flow to the participant at this x-coordinate.
Hi all. I am currently working on a somewhat bigger business analytical and executable model. I’d say an estimated 20% of my modeling time go into dealing with this single issue here: correcting the positions of message flows over and over again. It’s a real pain point - so let me vote myself to please vote this up and look into it!
This is only breaking on pool resize, never on move?
Regardless of your answer: I created a ticket for that. Seems like something really valuable to look into (judged by the time you spend fixing things),
If you have more other scenarios where you discover annoyances, please post them as a screen cast. Your input is important for us to be able to provide a sustainable solution.
I commented on the issue. Many thx!
We made huge improvements to message flow layouting. To ship with the next bpmn-js version. Please try that out, if you can and give us feedback.
For the moment just a quick response so that you know that I am still very much interested! A quick first test shows big improvements, indeed. However, there are also considerable issues left. I will come back to you with more qualified feedback asap, but may take some days until I find the time.