Community
Participate
Working Groups
Sirius ConnectionCreationTool extends org.eclipse.gef.tools.ConnectionCreationTool, which extends GEF's AbstractTool. This implementation listen to key events on the tool and provides useful methods via org.eclipse.gef.tools.AbstractTool.getCurrentInput(). But this method is protected, so the tool has to be extended to make those informations accessibles. There is no way in Sirius to redefine the tool, so could it be possible for Sirius ConnectionCreationTool (and any other tool extending GEF's tools) to provide a method accessing the current input ?
This issue describes a technical need but not the functional needed feature. Open as public the getCurrentInput() in Sirius is not neutral. It changes the contract offered by GEF. Have you more details about the functional feature?
What was needed was to check the current active keys on the current tool of the edit domain. The tool has a listener on keys, that can be accessed via the protected getCurrentInput method. To use it, GEF intends us to subclass tools, but Sirius doesn't allow to contribute tools.
This ticket describes a very specific technical change. Can you give us a hint of what is the actual functional issue that you're trying to solve? Maybe there are other, more general/cleaner ways to address it that this particular technical change.
I wanted to get the status of the CTRL key when a connection tool is used, in order to change the behavior of the tool depending of if the key is pressed or not. The connection tool is defined in the .odesign, and is intended to be connectable to the diagram edit part, i.e. can be used from a node to the diagram background. To implement this capability (as in to be enabled when pointing on the diagram background) I redefined the diagram edit part. With this approach I was able to redefine the behaviour of the diagram edit part when acknowledging a request from the connection tool. Now to get the status of the CTRL key, we must listen to the connector edit part. Fortunately GEF adds this listener, unfortunately it is protected as the intent was (I think) to make users redefine their own tool. This cannot be done with Sirius as it instanciates the tools declared in the odesign itself without providing a way to extend or hook on this part. Or maybe I missed something here ? To workaround that I get the active tool from the edit part API, which returns me the connection tool, on which I can access the key status... in a reflective way.
(In reply to William Piers from comment #4) > Now to get the status of the CTRL key, we must listen to the connector edit > part. Fortunately GEF adds this listener, unfortunately it is protected as > the intent was (I think) to make users redefine their own tool. > This cannot be done with Sirius as it instanciates the tools declared in the > odesign itself without providing a way to extend or hook on this part. Or > maybe I missed something here ? Well, yes and no. You're right it is not possible with Sirius, and the change you propose would probably work, but my point is that the underlying need "I wanted to get the status of the CTRL key when a connection tool is used" can probably be addressed in a cleaner and more general way that exposing an internal GEF method in our Java API. For example, Sirius could provide a general mechanism to expose the status of keyboard modifiers (and maybe other info) in a standard way that would be available to all tools. Thinking out loud here, don't take this as a commitment :) We could: 1. Define an EClass in our (internal) metamodel, named for example ToolActivationContext, which could have among others an attribute "modifierKeys : EInt" (a bitmask). 2. Define some EOperations or standard services on this type for easy access. Among others, isControlKeyPressed(). 3. Whenever a Sirius tool is invoked, create an instance of ToolActivationContext correctly setup, and expose it via a variable, say activationContext. This way, any tool could query the status of any modifier (or other information we would put there) from a standard interpreted expression. Would such a solution handle your case?
I'm rewording the ticket in a slighly more general way in line with my previous proposal. William, don't hesistate if you have more feedback or if I'm misunderstanding your issue.
