Improve origin adjustment feature

[nikku]

In order to limit the effect of this, could we also update the default template for new files to place the start event at x="140" y="188". Why that position? The x coordinate allows a start event with a maximally wide label to be visible when a model is opened and the palette uses two columns. The y coordinate allows using a standard-size embedded sub-process behind the start event without triggering the behavior implemented for this issue.

In fact the x="140" should be the destination to move to, because otherwhise the two-column palette on small screens covers the start event or its label.

Furthermore, I think the 'Move to origin' should be aligned with this, because otherwise users that used 'Move to origin' will have a hard time moving their diagrams to a position where its start event is not hidden behind the palette when they open the file. Basically, their only chance would be to use the space tool or create new elements in negative areas, to trigger the behavior implemented for this issue.

Originally posted by @falko in #982 (comment)

[nikku]

Thanks for your further input on the automatic alignment topic. Some remarks / questions:

In order to limit the effect of this, could we also update the default template

I agree with you that we should minimize the initial noise that #982 is generating. #1186 adds additional measures to prevent re-positioning on minimal updates, e.g. labels being added / expanded to full width. It assumes the default offset of (150, 150), taking into account your comment on the palette, too. You may checkout out bpmn-io/align-to-origin, the actual utility being used under the hood.

Furthermore, I think the 'Move to origin' should be aligned with this, because otherwise users that used 'Move to origin' will have a hard time moving their diagrams to a position where its start event is not hidden behind the palette when they open the file.

Is there a good reason to keep the manual alignment action around with the new feature being present? Pull request #1186 removes it if automatic alignment is set up.

[ingorichtsmeier]

If I want to export a diagram as picture, I didn't want to crop the picture manually afterwards.

The exported diagram should have a minimal border.

Maybe this implemented already, I want to make you to have this in mind when deciding how to progress.

[nikku]

If I want to export a diagram as picture, I didn't want to crop the picture manually afterwards.

The diagram will always be exported with a minimal border only.

[ingorichtsmeier]

Thank you for the clarification

[pinussilvestrus]

Closed via #1186

[falko]

Is there a good reason to keep the manual alignment action around with the new feature being present? Pull request #1186 removes it if automatic alignment is set up.

Yes, since the auto re-alignment is only triggered when elements are in the negative space, there might still be a use case, where one wants to bring a model that is too far down or too far right back to the "sweet spot" in the upper left corner.

[nikku]

Yes, since the auto re-alignment is only triggered when elements are in the negative space.

Automatic re-alignment is triggered all the time, as soon as diagrams are away from the sweet spot you mention by a considerable offset, cf. this visualization.

From my point of view this makes the move-to-origin feature obsolete. Let's wait for additional feedback regarding this and incorporate it.

[nikku]

I think especially the fact that the uses cannot know if a diagram is too far down anymore (diagram origin cross removed) makes it hard to argue for the move-to-origin feature to be accessible.

[falko]

Okay, let's see how it feels.