On Wed, 9 Oct 2024 14:50:34 GMT, Martin Fox <m...@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 crack 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. > > Martin Fox has updated the pull request incrementally with one additional > commit since the last revision: > > Clean up for coding standards and removal of unused fields Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1528#pullrequestreview-2357678982
