Marking synthesized scroll events as such.

[Alexander Nyssen]

Having started to work on JDK-8143596 <https://bugs.openjdk.java.net/browse/JDK-8143596> today, I have to provide an update on this: those PAN gesture events that are emulated by SWT should indeed be ignored by FXCanvas (as done by our FXCanvasEX implementation), because:

a) SCROLL gestures (START, SCROLL, FINISH) may otherwise not be properly recognized by JavaFX code (because they are always ‚disturbed‘ by intermediate synthesized mouse scroll events).
b) JavaFX does not emulate such events, so forwarding would result in a different behavior in case of the SWT integration (compared to JavaFX native).

Regards,
Alexander

> Am 16.08.2016 um 08:55 schrieb Alexander Nyssen <alexander at nyssen.org>:
> 
> Hi all,
> 
> as I am currently working on FXCanvas, there is one aspect I would like to discuss, which is closely related to JDK-8161282 <https://bugs.openjdk.java.net/browse/JDK-8161282> (FXCanvas does not forward horizontal mouse scroll events to the embedded scene) and JDK-8143596 <https://bugs.openjdk.java.net/browse/JDK-8143596> (FXCanvas does not forward touch gestures to embedded scene), namely handling of synthesized scroll events. That is, SWT synthesizes mouse wheel scroll events from PAN gesture events, and these are forwarded to the embedded scene (the patch I provided for JDK-8161282 does not change this behavior, it simply ensures horizontal and vertical mouse wheel events are processed equally) while not being marked as synthesized (unlike MouseEvent, ScrollEvent does not provide a ‚synthesized‘ flag). JavaFX natively seems to do likewise with SWIPE events, which seem to yield synthesized scroll events as well. 
> 
> Wouldn’t it be appropriate to introduce a synthesized flag and mark such kind of events as being synthesized? Within the Eclipse GEF’s FXCanvasEx we have sorted out scroll events synthesized form PAN events completely (and any client code may do likewise without accessing internal API, so this is no JIGSAW related issue), but I think it in general be nice if client code could properly decide, whether it wants to deal with these events or rather handle the native gesture events instead (as soon as JDK-8143596 is resolved this would even be possible in an SWT-integrated scenario).
> 
> I would raise an issue via webbug for this, if my thoughts are shared.
> 
> Regards,
> Alexander
> 
>