Necessity of com.sun.javafx.embed.AbstractEvents

[Alexander Nyssen]

Hi Artem,

> Am 17.09.2016 um 00:12 schrieb Artem Ananiev <artem.ananiev at oracle.com>:
> 
> Hi, Alexander,
> 
> I believe I introduced that extra abstraction layer for FX/Swing events long time ago. At that time, we thought we might eventually want to embed different components than just JavaFX, but it doesn't make any sense these days. JFXPanel and FXCanvas contain a lot of FX specific code, they can't be used to embed anything than FX. I agree that AbstractEvents is redundant and can be replaced by FX events.

thanks for clarifying this. I have raised JDK-8166242 <https://bugs.openjdk.java.net/browse/JDK-8166242> (Removal of com.sun.javafx.embed.AbstractEvents) to keep track of the issue.

> 
> BTW, SwingNode (which is opposite to JFXPanel, it's to embed Swing into FX) doesn't use AbstractEvents, but operates directly with FX events.

That sounds like an additional argument for the removal of AbstractEvents. Thanks for having pointed that out.

Just to mention it (in case somebody searches for such functionality), within GEF we have introduced something comparable for embedding SWT controls (in the context of an FXCanvas). We called it FXControlAdapter (https://github.com/eclipse/gef/blob/master/org.eclipse.gef.fx.swt/src/org/eclipse/gef/fx/swt/controls/FXControlAdapter.java). It’s still pretty basic, but might be a good starting point.
> 
> Thanks,
> 
> Artem

Best Regards,
Alexander

> 
> On 9/16/16, 2:03 AM, Alexander Nyssen wrote:
>> Hi Alexander Z., Kevin,
>> 
>> while working on JDK-8143596 (FXCanvas does not forward touch
>> gestures to embedded scene) I came across some „smell“ that I would
>> like to discuss. That is, the information about events that is
>> exchanged between JFXPanel/FXCanvas and the
>> EmbeddedScene/EmbeddedStage is currently encoded via constants of
>> com.sun.javafx.embed.AbstractEvents. That is, FXCanvas and JFXPanel
>> map SWT and AWT event information to constants in AbstractEvents,
>> which are finally mapped to a JavaFX representations within
>> EmbeddedScene.
>> 
>> Without knowing the motivation behind this indirection, and without
>> having tried it in detail yet, for me it seems as if AbstractEvents
>> was superfluous and JavaFX representations could directly be used to
>> transfer this information instead. In case of
>> EmbeddedSceneInterface#inputMethodEvent() for instance,
>> AbstractEvents was already bypassed, as here EventType is used as a
>> parameter (instead of an AbstractEvents constant). Also, the modifier
>> constants defined within AbstractEvents are only used in case of key
>> events, while for mouse (and now gesture events) boolean parameters
>> are used to transport this information (which could also be done in
>> case of key events).
>> 
>> What do you think? In case you share my assessment I would propose to
>> file a separate issue for this, and I could offer to investigate it
>> after JDK-8143596 has been resolved (I would not want to mingle it).
>> 
>> Best Regards,
> 
>> Alexander