Accessing Viewport Information on the server side

[jmenzies12]

Hey there,

I'm trying to center the nodes on the canvas after triggering a layout. However I'm having trouble accessing the Viewport from the server side, in the layout operation handler. I tried injecting the ActionDispatcher and sending a GetViewportAction but this appears to have no response.

Is there any way I can access this information?

I originally considered triggering a CenterSelection, however as far as I can see this simply moves the viewport, which means that the node positions are not changed and hence on reload the nodes go back to where they were before.

Using glsp-server-node and glsp-vscode-integration.

Cheers!
Jonathan

[martin-fleck-at]

Hi @jmenzies12, you are right, the CenterAction simply adapts the scroll of the viewport so that the selected elements are centered in view but it does not actually adapt the positions of any elements.

For what you are trying to achieve, dispatching a GetViewportAction will send the request from the server to the client but I believe there is currently no way to retrieve the response from the client. You could probably register a handler for the ViewportResult action on the server but overall I think it might be easier to use a custom action or extend the layout-trigger action with the information about the viewport that you need, i.e., the canvasBounds from the root element, together with the scroll and zoom if you need it, and handle that operation properly on the server.

[jmenzies12]

Hey @martin-fleck-at,

Thanks for the response and your suggestions. I ended up with a fairly good solution but let me know your thoughts.

The trigger action for layout in the vscode-integration, triggers LayoutOperation in the configuration-utils, as far as I'm aware this has no access to the viewport, and then LayoutOperation is sent direct to the server.

I had to do the following:

• Create a new action RequestLayoutAction and it's handler, in the client side, the handler retrieves the viewport information and then returns an extended LayoutOperation with that information that gets sent to the server.
• Override the LayoutOperationHandler (already done this so I can reconcile the layout result with my source model), so that it can get the viewport information and pass it on to the LayoutEngine.
• Override the GlspELkLayoutEngine, and create a new function layoutWithCentering that replaces LayoutEngine.layout in order to pass the LayoutOperation as a parameter.
• Create a new function, which is called from inside layoutWithCentering, that takes the resulting ElkGraph and then calculates the offset required to move all of the nodes, post layout, to be aligned with the center of the canvas. Then apply that offset to all of the nodes, before they are passed back to the LayoutOperationHandler.

I'm wondering here if maybe it would be good to update GlspELkLayoutEngine and the LayoutEngine interface to take an optional LayoutOperation parameter? Having to replace usages of LayoutEngine.layout with a new function is a bit of a pain.

I tried adding the centering to the extended LayoutOperationHandler, in the executeOperation function, however at this point I cannot access the resulting top level ElkGraph node that contains the suggested width/height of the layout.

[martin-fleck-at]

Hi @jmenzies12,

As far as I can tell, this is quite a nice solution that you have! As you mentioned there are certain things that complicate the solution a bit but I don't see any way to work around that at the moment.

• Yes, we need the extra action so we can create a custom or enriched operation that contains the viewport information as on the VS Code side we do not have access to the model root when triggering the layout.
• If you need the Elk result, then you definitely need to adapt the GlspELkLayoutEngine and not just the LayoutOperationHandler.
• Good suggestion about the optional LayoutOperation parameter, I think that makes sense. I'll discuss it with the team in what way we can best use the operation information in the layouter but there should be some way to provide it.

Overall a good solution and thank you for reporting back!

[jmenzies12]

@martin-fleck-at,

Thank you for spending the time to look over my solution and I appreciate you taking into account my suggestion. If you end up making an issue for it, then feel free to reply to this post or tag me on the issue and I can look into contributing a fix.

I will mark my previous reply with the solution as the answer so anyone else who wants to do this can make use of it.

[martin-fleck-at]

@jmenzies12 I created #1561 to track the issue. We are planning to do a release next week and I'd like to get that in as I think it is quite straight-forward and we can do it while staying backwards compatible easily.

I really appreciate the offer to look into a contribution but since there is a little bit of a deadline to it, I don't want to hold you to it. If you prefer, I can work on a solution and let you have a look at it to make sure it satisfies your use case. Please let me know.

[jmenzies12]

@martin-fleck-at
Great! Thanks for the heads up, I would love to contribute this and I should have the time to do it before your release next week. I will go over the issue and the repos today and leave any questions I have on the issue.

My plan is start working on it tomorrow, I don't think it should take me that long so hopefully I will have something to push up the same day.