Add context menu support

We’ve been working on a context menu support for GLSP and thought it might be useful to push this to Sprotty instead. What do you think?

The idea is that there is a generic IContextMenuService in Sprotty and depending on the context in which it is used (inside Theia, plain react app, or even Eclipse RCP) we bind a different implementation to this service that passes on the job of rendering the context menu to the “native” context menu implementation.

export interface IContextMenuService {
    show(items: MenuItem[], anchor: Anchor, onHide?: () => void): void;
}

The context menu providers in Sprotty could look like below (so they specify all details about a menu item and define which Sprotty actions are going to be executed on click). To decide whether an item is enabled or not, it can use the state of the model (e.g. selection as below):

@injectable()
export class DeleteContextMenuProvider implements IContextMenuProvider {
    getActions(root: Readonly<SModelRoot>, lastMousePosition?: Point): Promise<MenuItem[]> {
        const selectedElements = Array.from(root.index.all().filter(isSelected).filter(isDeletable));
        return Promise.resolve([
            {
                id: "delete",
                label: "Delete",
                sortString: "t",
                group: "a",
                actions: [new DeleteElementAction(selectedElements.map(e => e.id))],
                isEnabled: () => selectedElements.length > 0,
                isVisible: () => true,
                isToggled: () => false
            }
        ]);
    }
}

So far we’ve created an implementation for Theia based on Theia’s context menu support (see our work in progress implementation). Essentially it registers the commands, menu actions, and submenus in Theia as well as a special command handler that passes on the Sprotty actions to the action dispatcher. It currently supports grouping, submenus, icons, sorting, enablement, toggle, as well as putting menu items into a parent that some other provider defines.

This is how it looks like in action:

Before finalizing this change, I was wondering whether I should rather put it into Sprotty first and then do the GLSP integration (so that menu items can be provided also from a server). The work in progress implementation in GLSP is here: https://github.com/eclipsesource/graphical-lsp/commit/fa14b76a8d6c14d7f73f08169297bb942bec0b0f

Please let me know what you think! I’m happy to add this to Sprotty instead of GLSP only.

Happy Halloween! 😉

[spoenemann]

Ok, let’s include native support for context menus. We should have proper documentation of all first-class features at some point…

[planger]

Hi Miro,

thanks for the feedback! I think it is good to raise the question; it has a point!

You are certainly right regarding the selection, the viewpoint, and the action dispatching. This could all easily be done outside of Sprotty.

However, I guess that context menu item providers might benefit from the internal model in some cases, e.g. to test against features of model elements (e.g. deletable). Theoretically, this could also be queried via request/response actions that are sent from outside though. I’m not sure whether it would make things simpler, but it would be doable.

The mouse listener should probably also still be registered as a Sprotty mouse listener, right? The code of the mouse listener doesn’t necessarily have to live in Sprotty, though.

Are you suggesting that we rather put the entire code into the sprotty-theia integration or keep it in the applications only?

In the end, I think it also depends on how relevant the cross-platform use case for Sprotty diagrams is (that is, if we want to be able to define a Sprotty diagram once, and use it with minimal effort also in different platforms, such as Theia, Eclipse RCP, VSCode). Because if this use case is very relevant, then it imho makes sense to have a common way of defining context menus inside Sprotty and have integration code (such as sprotty-theia) that is translates those menus into the native way of rendering menu items in different platforms. If this use case is not relevant, then I guess it should be fine to have the context menu as part of the integration code to provide a framework for defining those.

Leaving context menu support entirely to the application (as opposed to the platform) might lead to code duplication though, as the code for defining menu items, rendering them on a platform, and sending actions back to the action dispatcher on-click would probably always be the same for each platform (Theia, etc.).

I think I would tend to having “Sprotty-native support” for menu items to be able to specify them as part of the Sprotty diagram; but I do get your point to avoid having to cope with menu items, registries and the like in Sprotty. So I’d understand, if you prefer to keep it out and keep menu item support outside of Sprotty (in sprotty-theia or even GLSP only).