Is there a way to get the viewport information when triggering Auto Layout?

[jmenzies12]

Hey there,

I hope you all got to enjoy the holidays.

As part of #1558, TriggerLayoutAction was added and the LayoutEngine was given an optional parameter to pass in the LayoutOperation. This works great for manually triggered layouting.

However when auto layouting, the layout engine is called directly by the server side code and it does not have access to the viewport information. I remember from previous conversations that we cannot currently send a request from the server to the client to retrieve this information.

I went down a rabbit hole of trying to get the server to instead return a TriggerLayoutAction as part of the submitDirectly function in the ModelSubmissionHandler, however this ends up triggering a ComputedBoundsAction which then triggers the layout resulting in an endless loop of layouting and reloading :). This is avoidable in all but one situation, when you first open the diagram, the ComputedBoundsAction is triggered and without that triggering TriggerLayoutAction the diagram is not laid out with the appropriate information.

Instead of going to much further down said rabbit hole, I thought I'd enquire if you had any better suggestions/possible workarounds?

Cheers
Jonathan

[martin-fleck-at]

Hi Jonathan,

Hope you had a good start into the new year as well!

The problem you are describing is definitely not very trivial with the current setup. As you said, the most straight-forward solution is to support server-side requests to the client. The only other instance that I can think of where we request data from the client is the request-bounds-cycle and here we solve that by having the ComputedBoundsActionHandler submit the model afterwards. This works nicely if we only have a single case but with two cases (requiring the bounds and the layout information) we need to be very careful with the timing to avoid flickering and unnecessary updates. If we have set the needsClientLayout (which semantically is true), then the cleanest solution for this would be to extend the ComputedBoundsAction with the canvas and viewport data we need so we can trigger the layout engine on the server side. We already extended this action for routing points and element layout data. I have not tried this yet, though, so this is all theoretical.

@tortmayr Do you have any preference between extending the ComputedBoundsAction (if possible) or trying to tackle #607?

[tortmayr]

I think for now it would be better if we try to to extend the ComputedBoundsAction.
We probably should tackle #607 in the near future. General server-side support for sending client requests would be preferable.
However, I believe that this requires more effort and testing and its probably easier to with the extension approach for now to support this feature as early as possible

[martin-fleck-at]

Thank you Tobias! I opened #1616 to track this and proposed a first solution in eclipse-glsp/glsp-client#458 and eclipse-glsp/glsp-server-node#121. @jmenzies12 That should also be something you can re-implement locally for now by re-binding the respective classes and providing the extension.

[jmenzies12]

Great! This sounds like a reasonable solution. Thank you