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. This pull request has now been integrated. Changeset: ec60af47 Author: Martin Fox <m...@openjdk.org> URL: https://git.openjdk.org/jfx/commit/ec60af479b824da521b14522c07d814e08dea3e5 Stats: 316 lines in 13 files changed: 265 ins; 11 del; 40 mod 8087863: Mac: "Select All" within ListView/TreeView is handled differently depending on the useSystemMenuBar value Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1528
