On Thu, 8 Aug 2024 17:38:19 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
> Thinking out loud for a moment: wouldn't it be better to use a kind of > EventFilter specifically for the shortcuts, before the normal dispatching > happens? I think I see where you’re going here. We could send the KeyEvent into the scene graph and then catch it on the back end to be processed by the system menu bar. If the KeyEvent reaches the KeyboardAcceleratorHandler we know that it’s time for the menu bar to process it. I’ve thought about this but it would tricky to implement. Currently we only send a subset of key events to the system menu bar (the one’s that are delivered to us via performKeyEquivalent). Once a KeyEvent is injected into the scene graph we lose track of whether it was generated by performKeyEquivalent or keyDown. We could also see KeyEvents that weren’t created by glass (anyone can create one). We would have to find a way to sort this out on the back end. What truly makes me nervous is how we would have to alter the normal performKeyEquivalent flow. Usually NSApplication controls the order in which key equivalents are presented to different components (windows, views, the system menu bar, etc.) To implement this alternative approach we would have to short circuit the NSApplication flow and present events to the system menu bar manually. This PR is the most conservative one I could come up with since it doesn’t change the order of event processing and fits into the normal performKeyEquivalent flow that NSApplication expects. It just avoids double-processing of the same event. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2282197287
