The "sticky" Orca modifier doesn't work in the new-keyhandling + Wayland world
The possibility of making the Orca modifier "sticky" (as in StickyKeys) was done in commit e4ca7e18. The way it works appears to be the following:
- If sticky keys is enabled (as determined by xkbset), keep track of any pressed modifiers -- including the Orca modifier.
- Apply those modifiers to subsequent events.
- When a non-modifier event comes in (e.g. "H"), apply the previous modifiers to that non-modifier event in
KeyboardEvent.__init__()
, then reset the "stuck" modifiers. - When it was then time to determine if we were going to consume that officially-unmodified "H" we would see the applied Orca modifier and consume it.
In the new-keyhandling world, this doesn't work. We no longer have the luxury of consuming all input events, applying non-standard/unrecognized modifiers after the event was emitted.
From what I can tell so far, what's going on is:
- We've registered grabs and modifier grabs for the Orca modifier (at least in the case of the desktop layout), but
- Nothing is applying the Orca modifier to the non-modified event (e.g. "H") so that the non-modified event gets modified and seen as one of our commands/grabs. Note that grabs + sticky keys works for non-Orca modifier bindings. For instance, I created a binding of Ctrl+Alt+Shift+N for the Notification Presenter, enabled sticky keys, and then pressed and released Ctrl, then Alt, then Shift, then N. Worked just fine.
Beyond these issues, we really should not be depending on xkbset. There should be a way to identify if Sticky Keys is enabled -- ideally a desktop-environment-agnostic way -- and we should use that instead.
@mgorse, @cwendling: Thoughts?