Support enabling and disabling tools at runtime

Especially when providing editing support, but also in other scenarios, it is useful to support enabling and disabling diagram tools, such as a node or edge creation tools, deletion tools, but also for non-editing scenarios, e.g. a special selection tool (for instance allowing to draw a rectangle with the mouse and every element that intersects will be selected). In traditional diagram editors, the enablement and disablement of tools is typically controlled by the user via a palette.

Currently, there is no dedicated infrastructure to control the enablement of tools in Sprotty. Tools are usually registered via DI, typically in the form of key and mouse listeners, and then remain active throughout the lifecycle of the diagram widget.

Therefore, we introduced a ToolManager in the graphical-lsp framework, which keeps a list of available tools and which manages their state. The tool manager itself is controlled via an action handler that reacts to dedicated actions (e.g. EnableToolsAction), so palette implementations can enable or disable tools by sending those actions. On each action enablement or disablement, the tool manager initializes or disposes the respective tools, which allows them to register and unregister their listeners, as well as to perform any arbitrary diagram modifications, etc., such as setting it up for visual feedback in the diagram, etc. that can later be cleaned up when the tool is disabled. To accommodate for the typical scenarios, the tool manager supports two types of tools, standard tools and “other” tools. Standard tools become active in the common user-interaction state until other tools are explicitly activated. Once a tool is finished or the user escapes the current interaction mode, all standard tools can be activated again.

We think this infrastructure might be interesting for Sprotty in general and not only for the graphical-lsp use case. If you agree, we’d be happy to open a PR. Please let us know what you think?

[planger]

Thanks for your feedback!

I’ll then prepare a PR at latest beginning of Dec and we can continue the discussion on this PR then. I’m sure there might be some more additional capabilities needed in the manager to address all use cases. But I think this can more easily be sorted out in the PR.

Note: We currently have a lot of overlap, dependencies and ordering problems in the handling of events between the different “tool” usecases, resulting in some mix of responsibilities, e.g. the MoveMouseListener also manages editing of routing points, reconnecting edges and deletion of elements. Would be great if your approach addressed that such that we can compose behavior more clearly.

Right, that’s also what we have observed in our GLSP-specific listeners. Especially in those that are essentially supposed to only do something in specific use cases/modes. For us, another big advantage of the enablement and disablement of tools is that their statefulness is safer to manage (e.g. storing a previous selection when drawing an edge) and prepare/clean-up on enablement and disablement, e.g. for visual feedback or mouse decoration, etc…

I’m not sure that the tool manager solves the problem regarding the order of events though. However, it should allow us to separate concerns better and make the tools leaner as they can be more focused on a specific task.

Thanks again!

[spoenemann]

Yes.