RFR: 8087863: Mac: "Select All" within ListView/TreeView is handled differently depending on the useSystemMenuBar value
Andy Goryachev
angorya at openjdk.org
Thu Aug 8 17:40:37 UTC 2024
On Fri, 2 Aug 2024 19:07:35 GMT, Martin Fox <mfox at openjdk.org> wrote:
> macOS processes a shortcut key like Cmd+A in two phases. In the first phase it’s shopped around as a “key equivalent”. If it’s not consumed as a key equivalent it enters the second phase and processed as a normal keyDown event. Among other things the key equivalent phase ensures the shortcut will be seen by the system menu bar *before* being treated as a keyDown. This is the opposite of how JavaFX works; it expects a key event to be fired at the current focus node which gets first crash at the event before it works its way out to the menu bar.
>
> We can’t really opt out of the key equivalent phase but we can get the event before the system menu bar does. Our implementation of performKeyEquivalent pushes the event through the JavaFX scene graph but has no way of knowing if the scene graph consumed it. The result is that a consumed event is always handed to the system menu bar where it can also trigger a menu item.
>
> This PR introduces a variant of notifyKey that returns a boolean indicating whether the event was consumed or not. If the event was consumed performKeyEquivalent doesn’t allow it to continue on to the system menu bar.
>
> I’m trying to fix this old, old problem because I’ve seen at least one JavaFX app tie itself up in knots trying to work around this. Despite the number of files being touched it is not a deep fix; there’s just a boolean return value that needs to be plumbed through multiple layers.
Thinking out loud for a moment: wouldn't it be better to use a kind of EventFilter specifically for the shortcuts, before the normal dispatching happens?
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2276339875
More information about the openjfx-dev
mailing list