Re: Necessity of com.sun.javafx.embed.AbstractEvents

[Alexander Nyssen]

Hi Artem,

> Am 17.09.2016 um 00:12 schrieb Artem Ananiev :
> 
> 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 
 (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

Re: Necessity of com.sun.javafx.embed.AbstractEvents

[Artem Ananiev]

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.


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


Thanks,

Artem

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

Necessity of com.sun.javafx.embed.AbstractEvents

[Alexander Nyssen]

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