|
| Re: [Zest] How to add an DoubleClickListener to the ZestContentViewer? [message #1728438 is a reply to message #1728418] |
Mon, 04 April 2016 11:24   |
|
Hi Christoph,
yes you can handle mouse interactions, however, you need to implement an interaction policy instead of registering an event handler. An example for a such an interaction policy is the OpenNestedGraphOnDoubleClickPolicy that is contained within Zest.FX.
The policy creates an (undoable) operation within the click() callback method and executes that operation on the domain (so that it is placed on the operation history). A binding is defined for the policy within the ZestFxModule (see #bindNodePartAdapters()).
Generally, to create a new policy to handle mouse click interactions, you can proceed as follows:
1) Create a new YourActionOperation class that extends org.eclipse.core.commands.operations.AbstractOperation and implements ITransactionalOperation. Implement the execute(), undo(), redo(), isNoOp(), and isContentRelevant() methods to fulfill the operation contract.
Note, that it might be convenient to create a transaction policy (see AbstractTransactionPolicy) that can be used to obtain an operation that will perform the desired changes. For an example, take a look at the FXTransformPolicy (transaction) and the related interaction policies (e.g. FXTranslateSelectedOnDragPolicy).
2) Create a new YourActionOnDoubleClickPolicy class that extends AbstractInteractionPolicy<Node> and implements IFXOnClickPolicy. Within the click() callback method, check that the click count equals two (double click), create an instance of YourActionOperation that will perform the desired changes, and execute that operation using getHost().getRoot().getViewer().getDomain().execute(operation).
Note, if you are using a transaction policy, instead of creating the operation directly, you can use the transaction policy to create the operation.
3) Create a new YourModule class (if you do not have one already) that extends ZestFxModule and override the #bindNodePartAdapters() method. Call the super method and add a binding definition for the YourActionOnDoubleClickPolicy class as follows:
//...
protected void bindNodePartAdapters(MapBinder<AdapterKey<?>, Object> adapterMapBinder) {
super.bindNodePartAdapters(adapterMapBinder);
adapterMapBinder.addBinding(AdapterKey.role("your-action")).to(YourActionOnDoubleClickPolicy.class);
//...
The policy will then be called for all mouse click interactions on nodes. If you only want to perform the changes for particular nodes, you need to add checks to the interaction policy to prevent it from executing operations when it should not.
Best regards,
Matthias
|
|
|
| Re: [Zest] How to add an DoubleClickListener to the ZestContentViewer? [message #1728561 is a reply to message #1728438] |
Tue, 05 April 2016 13:06 |
 Christoph Broeter
Messages: 30
Registered: July 2015 |
Member |
|
|
Thx Matthias for your help.
In the meanwhile I've figured out how to add a MouseListener:
I've done an inheritance from the ZestContentViewer and casually added following two methods:
import org.eclipse.gef4.zest.fx.ui.jface.ZestContentViewer;
import org.eclipse.swt.events.MouseListener;
public class MyZestContentViewer extends ZestContentViewer{
public MyZestContentViewer(){
super();
}
public void addMouseListener(MouseListener m){
this.getControl().addMouseListener(m);
}
public void removeMouseListener (MouseListener m){
this.getControl().removeMouseListener(m);
}
}
works as intended.
Hopefully this will be helpful for other interested people.
[Updated on: Tue, 05 April 2016 13:10] Report message to a moderator |
|
|
| Re: [Zest] How to add an DoubleClickListener to the ZestContentViewer? [message #1728787 is a reply to message #1728561] |
Thu, 07 April 2016 11:40 |
|
Hi Chirstoph,
I just want to clarify, since you did not try out the policy-based solution, defining your own event listeners is possible, but it does not fully utilize GEF4 and suffers from:
* poor reusability
* no automatic target selection
* operations not performed on the undo-stack
* execution order (eventually) non-deterministic
That's why this is not the intended approach. However, the approach is still valid in case you do not need any of these features for the particular action associated with the event listeners.
Best regards,
Matthias
|
|
|
Powered by
FUDForum. Page generated in 0.03122 seconds
] 
Search
Help
Register
Login
Home
