This library reduces the gap between native applications and AWT/Swing applications, providing a more consistent and pleasant UI/UX. Why this? Why Swing? Well, this might finally address JBR-4083 and IDEABKL-6039, issues that have been open for 15 years. Also, I wanted to build a feature I’ve always missed in JetBrains IDEs.
With this, we can use two fingers swipe gesture to navigate back/forward also within Swing applications on macOS, as we do on Xcode and Safari. This gesture is largely used for navigation in many AppKit-built programs, but the JDK only supports discrete gestures (namely, 3-finger swipe gestures via com.apple.eawt.event).
The video demo shows the library in action within IntelliJ IDEA (this is just a proof of concept, so the code might be suboptimal), providing a truly native-like experience—I implement 'two finger swipe' for back/forward navigation.
Currently, it operates as an application-level JNI bridge: it intercepts suitable NSEvents globally on the AppKit thread. This might not be the best, as ideally, you should not have to call (start/stop)EventMonitoring methods—you'd like to have this in libawt_lwawt.
The key challenge is disambiguating a logical fluid-swipe from a standard horizontal scroll, as trackpads trigger both via the same physical movement. For example, to implement the scroll/fluid-swipe coexistence mechanism, the library introduces a hierarchical veto mechanism. Any AWT/Swing component under the cursor can "block" (veto) an incoming fluid-swipe gesture by suitably implementing the method 'public boolean permitFluidSwipeGesture(FluidSwipeEvent e)' , which is queried on the EDT from the dispatcher. Ideally, fluid-swipe gestures should have a lower priority than scroll event. For example, a horizontally scrollable JScrollPane accepts the fluid-swipe iff there is no remaining scrollable content in that direction; otherwise, it vetoes the fluid-swipe, causing the dispatch of MouseWheelEvents. Note also that permitting an incoming fluid-swipe results in MouseWheelEvent not being dispatching as expected.
I am open to discuss any core aspect of the library and of the proof of concept, such as the scroll/fluid-swipe coexistence mechanism, and the API. Any feedback (and maybe help) would be greatly appreciated. What about extending this to Windows and Wayland?
I have tested it on macOS 26 (Tahoe) (Intel). Please test it on Apple Silicon and with Magic Mouse. The library has been sitting on GitHub and Maven Central for a couple of years (since 2024), but I've only now decided to dust it off, and ask for feedback.
anticleiades•1h ago
Note: I developed this in the pre-LLM/Code agents era
anticleiades•1h ago
IntelliJ Fork (the proof of concept): https://github.com/anticleiades/intellij-community/tree/poc-.... Please use the poc-fluid-swipe branch.
Video Demo (if you don't want to recompile everything): https://drive.google.com/file/d/1ZjAy6LEEP4ASg1-Zx68pHYaPjBp....
This library reduces the gap between native applications and AWT/Swing applications, providing a more consistent and pleasant UI/UX. Why this? Why Swing? Well, this might finally address JBR-4083 and IDEABKL-6039, issues that have been open for 15 years. Also, I wanted to build a feature I’ve always missed in JetBrains IDEs.
With this, we can use two fingers swipe gesture to navigate back/forward also within Swing applications on macOS, as we do on Xcode and Safari. This gesture is largely used for navigation in many AppKit-built programs, but the JDK only supports discrete gestures (namely, 3-finger swipe gestures via com.apple.eawt.event).
The video demo shows the library in action within IntelliJ IDEA (this is just a proof of concept, so the code might be suboptimal), providing a truly native-like experience—I implement 'two finger swipe' for back/forward navigation.
Currently, it operates as an application-level JNI bridge: it intercepts suitable NSEvents globally on the AppKit thread. This might not be the best, as ideally, you should not have to call (start/stop)EventMonitoring methods—you'd like to have this in libawt_lwawt.
The key challenge is disambiguating a logical fluid-swipe from a standard horizontal scroll, as trackpads trigger both via the same physical movement. For example, to implement the scroll/fluid-swipe coexistence mechanism, the library introduces a hierarchical veto mechanism. Any AWT/Swing component under the cursor can "block" (veto) an incoming fluid-swipe gesture by suitably implementing the method 'public boolean permitFluidSwipeGesture(FluidSwipeEvent e)' , which is queried on the EDT from the dispatcher. Ideally, fluid-swipe gestures should have a lower priority than scroll event. For example, a horizontally scrollable JScrollPane accepts the fluid-swipe iff there is no remaining scrollable content in that direction; otherwise, it vetoes the fluid-swipe, causing the dispatch of MouseWheelEvents. Note also that permitting an incoming fluid-swipe results in MouseWheelEvent not being dispatching as expected.
I am open to discuss any core aspect of the library and of the proof of concept, such as the scroll/fluid-swipe coexistence mechanism, and the API. Any feedback (and maybe help) would be greatly appreciated. What about extending this to Windows and Wayland?
I have tested it on macOS 26 (Tahoe) (Intel). Please test it on Apple Silicon and with Magic Mouse. The library has been sitting on GitHub and Maven Central for a couple of years (since 2024), but I've only now decided to dust it off, and ask for feedback.