Consider the Global Shortcuts Portal
After a few long conversations with wayland-protocol implementers, and within the GNOME accessibility matrix room, most seem to be relatively happy with the new shortcut protocol used by Orca to be usable via the global shortcuts portal, which doesn't currently have an implementation in GNOME. Although KDE already has one.
There is, however, one big downside to this portal, and that is that Orca (or libatspi
for that matter) will no longer be able to conditionally consume keys.
Whenever the user is in a context to use certain keybindings, and updated list of bindings will need to be sent to the portal. The list would look something like this:
-
Capslock + a
:orca:focus-mode-toggle
-
h
:orca:structural-navigation-heading
-
Capslock + w
:orca:read-window-title
- etc...
If a user finds themselves in focus of an input box, or leaves, or moves from a document to an application—a new set of keybindings will need to be sent. This will let the compositor know that you are now listening for different keybindings.
Interrupting key presses and releases as they come in is universally disliked amongst the Wayland crowd. They already need to implement some portions of that kind of logic for input method editors and apparently it causes a lot of headaches. This also has the huge advantage of being able to be implemented with any display server: X11, Wayland (Yayland, Zayland...) as long as they support the protocol.
There is one feature of Orca that would not work under this new protocol:
Pass the next command on to the current application: Orca Modifier+BackSpace
As far as I can tell, everything else should work, if the protocol is implemented properly, allows for capslock and insert as a modifier, and performs reasonably.
Before I go off spending weeks or months implementing a portal implementation for GNOME. I'd like to know if you're on board with this, @joanmarie and @mgorse .
Would Orca have any other issues using this new protocol?