On Thu, 2 Apr 2020 22:04:55 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
>> As noted in the JBS issue, this bug is a result of a deliberate change by >> Apple that affects applications (in this case >> the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two >> methods that we are relying on, >> `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation >> warning or any other indication at compile >> time or runtime that these methods are ineffective. They just stopped >> calling them. It is documented in their developer >> guide: >> [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc) >> Note that it's the version of the MacOSX SDK that the JDK is linked with >> that matters. JavaFX gesture notification >> works when run on a JDK that was linked against the 10.10 SDK or earlier >> (regardless of what MacOSX SDK was used to >> link the JavaFX libraries). JavaFX gesture notification fails when run on a >> JDK that was linked against the 10.11 SDK >> or later. The solution, as indicated in the Apple documentation referred >> to above, is to use the phase information >> from gesture events to track when to call begin / end gesture. The fix does >> the following things: 1. Removes the >> `beginGestureWithEvent` and `endGestureWithEvent` responder methods in >> `GlassView2D` and `GlassView3D` 2. Calls new >> local methods from each gesture to track when to call the associated >> `GlassViewDelegate` notification methods, >> `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent` I've tested this >> on macOS 10.13.6 and 10.15.3 (Catalina) and >> the attached program now runs correctly. I also tested the GestureEvent >> sample in Ensemble8 and it reproduces the >> problem before the fix and works correctly after the fix. I instrumented >> the code with print statements (which I have >> since reverted) and verified that the stream of events is as expected, and >> matches JDK 8u241 with bundled FX. > > @arapte Can you be one of the reviewers? > > @mipastgt I ran it against your test application, but if you have other tests > you could run, that would be helpful. I've built a fresh JFX, with your changes applied to master, this morning. I can confirm that the primary bug seems to be fixed with these changes but I have observed some behaviour where I am not sure whether it is correct or whether my expectation is just wrong. 1. The total delta values are now accumulated correctly for the regualar scroll events but not for the following generated inertia events. They are still equal to the delta values. Is that according to the specification? From a practical point of view a programmer who relies on the total delta values is probably much surprised if the total delta is reset by the inertia events. 2. Is the touch-count field only valid for touch-events or why is it always zero? 3. The mouse-wheel behaviour is still wrong because the total-deltas for mouse-wheel generated scroll-events is still not 0 but this has probably another root cause. ------------- PR: https://git.openjdk.java.net/jfx/pull/156
