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. is there a compelling reason we are not using Event::isConsumed? Maybe this case should also propagate `::isConsumed` flag similarly to #1523 It looks to me we are trying to invent band-aids to what appears to be a design problem (cloning the events regardless of their `::isConsumed` state) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2287194575 PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2289099708
