On Wed, 14 Aug 2024 15:20:58 GMT, Andy Goryachev <ango...@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. > > 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) @andy-goryachev-oracle Can you also review? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2400213875
