|
|
| Re: GEF5 + e(fx)clipse // Problem DragNDrop Shapes (Double Click ?) [message #1791882 is a reply to message #1791841] |
Fri, 06 July 2018 13:11   |
|
Hi Shawn,
I have used GEF inside pure JavaFX-rendered Eclipse before some time ago, so I believe it should work pretty seamlessly, a few things need special care though (e.g. domain activation), but no big deal.
If I was facing your problem (interaction does not work as expected), I would start debugging the corresponding handlers, i.e. FocusAndSelectOnClickHandler and TranslateSelectedOnDragHandler. There are methods for processing respective input events (click(), press(), drag(), release()) where the JavaFX event objects should arrive.
The FocusAndSelectOnClickHandler should execute operations that set the clicked part as the focus part inside the FocusModel, as well as adding it to the selected parts inside the SelectionModel.
The TranslateSelectedOnDragHandler should execute operations that transform the selected parts according to the drag event data.
Therefore, the JavaFX focus concept should not interfere with processing these mouse events on the GEF side. The problem should be different from the DndTabPane becoming the focus owner.
If the respective callback methods for processing input events are not visited, i.e. click(), press(), and drag() are not called, then you need to go one step further and investigate what is happening inside the ClickDragGesture that forwards mouse input events to GEF handlers.
Inside ClickDragGesture, you can find a JavaFX mouse event filter (JavaFX filter vs. handler: filters are executed while traveling from the root to the event target, handlers are executed on the way back to the root) that should receive all JavaFX mouse input events. If it does not get the click and drag events, something is really broken.
Feel free to report back.
h2h
Matthias
|
|
|
| Re: GEF5 + e(fx)clipse // Problem DragNDrop Shapes (Double Click ?) [message #1791972 is a reply to message #1791882] |
Mon, 09 July 2018 08:45 |
 Shawn Kleese
Messages: 3
Registered: January 2018 |
Junior Member |
|
|
Hey Matthias,
i have spend for this Problem some more Time and i have found now a Workarround.
The InfiniteCanvasViewer has a "isViewerFocused()" Method. This Method is used in the Eventhandling to prevent Eventhandling if it returns false.
So this mechanism works internally in the way, that it registers a Focus-Changed Listener on the the Scene and checks if the focused Node is IN the Viewer to say if the Viewer is focused/active.
At the End of this Chain the ClickDragGesture knows the activeViewer gets null. See this Snippet
org.eclipse.gef.mvc.fx.gestures.ClickDragGesture
private ChangeListener<Boolean> viewerFocusChangeListener = new ChangeListener<Boolean>() {
@Override
public void changed(ObservableValue<? extends Boolean> observable,
Boolean oldValue, Boolean newValue) {
// cannot abort if no activeViewer
if (activeViewer == null) {
return;
}
// some more Code ...
// ....
}
};
And when the DnDTabPane becomes FocusOwner the Viewer returns "isViewerFocused() --> false" and the Drag'n Drop does not work.
Now, my Workaround:
import org.eclipse.gef.mvc.fx.viewer.InfiniteCanvasViewer;
public class MyIfiniteCanvasViewer extends InfiniteCanvasViewer {
@Override
public boolean isViewerFocused() {
return true;
}
}
Register the MyIfiniteCanvasViewer instead of the Default-Implementation
public class MyFxModule extends MvcFxModule {
@Override
protected void bindIViewer() {
binder().bind(IViewer.class).to(MyIfiniteCanvasViewer.class);
}
/**
Here are some more Code
**/
}
This currently work for me, but i suppose that this Viewerfocused-Mechanism have some Reasons and i have disabled this Feature completly...
Do you know more about it?
Best Regards,
Shawn
[Updated on: Mon, 09 July 2018 11:19] Report message to a moderator |
|
|
| Re: GEF5 + e(fx)clipse // Problem DragNDrop Shapes (Double Click ?) [message #1793608 is a reply to message #1791972] |
Sat, 11 August 2018 13:58 |
|
Hi Shawn,
the focus mechanism plays together with aborting user interaction, i.e. if the viewer loses focus during user interaction (e.g. you drag something and switch to another application while dragging), that interaction is not continued. If that behaviour is undesired or unnecessary in your case, then you should be fine with keeping the viewer "focused". It could also lead to problems with multiple viewers in the same domain, but nothing that should give you headaches.
Nonetheless, I could imagine a slightly different solution that has less side effects: keeping the viewer focused if either itself or a DnDTabPane is the current focus owner.
Best regards,
Matthias
|
|
|
|
Powered by
FUDForum. Page generated in 0.04664 seconds
] 
Search
Help
Register
Login
Home
