"Floating" nodes - implementation hints or suggestions?

[paulreuter]

I have some use-cases where I want elements displayed in an overlay and/or sidebar. Typically, that could be realized with an UIExtension.

However, I'd also like to use some of the node/view amenities with these elements:

• content should be createable by the model factory
• internal client side layout
• selectable (for property views)
• possibly drag'n'drop into the main graph
• connectable

It seems that these should be full blown nodes, but simply positioned outside the regular diagram (in their own background or layout).

My thoughts on how this could be implemented:

1. fake the overlay by positioning an overlay node in the graph, counteracting translations and scale so the screen appearance is constant
2. Have the UIExtension retrieve the model+view and call the render method itself. The nodes would need to be in a part of the modelroot that is not normally rendered by the diagram, but still accessible by the UIExtension
3. render the nodes regularly in the diagram, then have the UIExtension edit the dom and steal the visible overlay VNode
4. use regular model+view, but the Views render method writes VNodes to the UIExtension. Might cause problems with model lookup when targeting actions. Also, does the hidden rendering for layout need to be in the diagram, or could it also be part of the UIExtensions DOM?

I am not sure what additional steps each approach would need so the lookup of SModelElement from VNode still works in each approach.

I'd be grateful for some experiences or hints on this subject.

[planger]

Interesting! I don't have first-hand experiences with such a use case, especially if it is supposed to be a fully editable diagram overlay.

In addition to the options you mentioned, you could also just try to go with two separate GLSP diagrams (main and supplementary), which may connect to the same GLSP server, but happen to be rendered in different parts of the UI (e.g. as a side panel). We did something similar by extending the GLSP Diagram Widget, e.g. in Theia, to render more widgets than just the GLSP diagram widget in the editor. In your case, it would then be two separate GLSP diagram widgets rendered in the same editor. How you arrange those two widget is up to you, but obviously easier if they are side-by-side horizontally or vertically.

With a separate GLSP diagram widget and a separate request-model-call cycle (as if it would be a completely independent editor), using the same model factory, include connectables, and using client side layout would work out of the box. Publishing the selection to the tool platform and implementing drag&drop would work by adding some event handlers for drop-events in the respective "independent" GLSP widgets.

I don't know how both of these views are logically connected, but this syncing would have to be handled in the server, as the server would get two separate clients and would itself have to figure out that those are actually connected in some way (e.g. via a common id). So with this approach you move the complexity of syncing the state (if it is complex in your use case) to the server. Consequently, this approach is straightforward if there is no complex syncing between the two view states needed.

Alternatively, if above seems infeasible, I lean towards approach 1 or 2. Whether 1 or 2 is better depends imho on whether the supplementary view needs full editing support or is rather static. If it is static, approach 2 feels rather straightforward, you could obtain the model state, which contains the nodes to be rendered (and hidden in main) and call the rendering from the GLSP client yourself from the UI extension. You wouldn't need to worry about viewport changes (panning and zooming). If editing support is key, there may be focus issues and tool state issues with that approach.

In that case, approach 1 may be better, because then you'd just need to counteract the viewport changes, which seems ugly, but should work technically. Approaches 3 and 4 seem like risky to break some assumptions in the code (now or in future versions).

I'm sorry that I can't give a clearer indication, but it very much depends on:

• Is it actually an overlay or a sidepanel, and is it in Theia, VS Code, Eclipse?
• Is the sidepanel/overlay a rather static diagram rendering, or is it a full-fledged editor.
• How do the sidepanel/overlay and main interact with each other, aside from selection and drag&drop?

[paulreuter]

Thank you for your thoughts and comments. I will try my luck with approach 2 first and see how far I get. There are actually a couple of different use cases so I'll work my way from easy to hard:
One overlay should show and allow editing the properties of different edge types with their current dash pattern/color. The edge types are themselves associated with parameters, are part of the data model and may be created and deleted.
One overlay might serve as a connection proxy to indicate where groups of edges are connected to (either nodes/group of nodes outside the visible area of the canvas, or from a different diagram)
One sidebar should serve as staging area to display unassigned elements, draggable onto nodes of the diagram.
Another sidebar serves as an access point to nodes of a conceptually different diagram (realized with a delegating nodefactory). These may have some internally structured view + layout and may contain multiple ports with different semantics, so I'd like to reuse their view from their other diagram as well as needing connectivity tools.

Of course, at most one of these is present in any given diagram, or the visual clutter would be terrible :-)

The main thing in common is that there is no need for a free form or persisted layout in the sidebar (VBOX would be sufficient), and that editing is typically limited to interactions and to the main diagram.

Currently, the diagram editor is targeted at eclipse RCP, with the intention to pivot to a full browser environment when the editing coverage is sufficient. We'll see if the standalone diagram editor covers everything or if embedding in Theia makes more sense (there will still be a java backend running, so presumably a lot of overlap with the benefits of Theia.