On Fri, 2 Aug 2024 19:07:35 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. Taking this out of Draft. To ensure consistent handling of the IM both `keyDown:` and `performKeyEquivalent:` use the same routine. There's a check to ensure that the same event doesn't get processed twice which mimics an older check that used to be in the view delegate. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2293854333
