Re: [orca-list] Pluginsystem for Orca using libpeas



Hi Chrys,

One thing that you should be aware of, since it likely ties into the work that you are doing, is that AT-SPI has a new API for handling key grabs. This is needed because, historically, Orca was notified of key presses via the AT-SPI registry daemon, which in turn relied on toolkits such as gtk to notify it of key presses. Gtk 4 no longer sends these notifications (see https://gitlab.gnome.org/GNOME/gtk/issues/1739 if you want more background there). AT-SPI has a new API which is intended as an abstraction to allow Orca to handle grabbing and monitoring keys. It currently has a back end for X11 and a back end for the legacy registry-based method. A wayland/mutter back end is TBD (we need to find a solution for this).

From Orca's point of view, the main difference is that Orca would now need
to proactively make a call to AT-SPI when it wants to grab or ungrab a key, rather than asking to be notified of all key presses and notifying AT-SPI whether it is going to consume the key after the fact.

I have an open merge request to have Orca use the new API[1]. But it is a minimalist change intended to get things working; if you are going to comprehensively refactor key bindings, then you might want to do things differently from what I have done.

[1] https://gitlab.gnome.org/GNOME/orca/-/merge_requests/109

Thanks,
-Mike

On Sat, 5 Jun 2021, Linux A11y wrote:

Howdy Joanie,

right, i thought about that. Thats good, so we agree :). Let met hammer in my own branch and lets do some review after having some milestones beeing done. Lets use your milestones for an initial batch.
For those i leave a new GUI and settings handler out of mind. Lets concentrate on the plugin stuff and its 
issues and its „hardening“ first. If we know we can trust the way to go and wiped out its basic issues, we ca 
go another step.

So first level will look like:
* date-time: using current setting mechanism and UI
* clipboard: using current setting mechanism and UI * notifications list: should work as usual ( i don’t know that functionality yet, have to take a look, sounds* like a history for the desktop wide notifications to me)
* mouse review: should work as excepted, be able to consume the needed events and data.

I do all this with currently used settings structure and UI.

Then we do the first batch of review and cleanup, to have it in a shape we can agree to.

Having this done and we know that and how it works, we should think about an UI concept and settings 
Management (to avoid touching every plugin twice) what do you think? So we can do it the right way, just from 
beginning.
Do you agree?

Cheers chrys


* date-time: two keybindings and one (I think) setting
* clipboard: one keybinding I assume, and maybe no settings?
* notifications list: which is more or less a mode once invoked
* mouse review: which needs to listen for events and sometimes know something about where the object came 
from (e.g. Gecko).


Am 05.06.2021 um 15:13 schrieb Joanmarie Diggs <jdiggs igalia com>:

Hey Chrys.

About to run out the door, but regarding this:

well, but what comes to my mind, if we wanna do this, how should we behave in development?
sending every single patch for an huge undertaking like that could be
a huge overhead for you to review. whats the best way here?
or should i continue my branch on github ( i can give you write
access changes back then? just asking, because it might require a lot of changes in height frequency.
what do you think?

I definitely don't want a zillion patches. And I think we'll want to do
it in logical chunks which then get merged as a single commit, or maybe
a few.

I think the first set should be things like simple user commands. Leave
the hello worlds and moving of screen reader messages out of the
picture for now.  I think a good first set would be:

* date-time: two keybindings and one (I think) setting
* clipboard: one keybinding I assume, and maybe no settings?
* notifications list: which is more or less a mode once invoked
* mouse review: which needs to listen for events and sometimes know
something about where the object came from (e.g. Gecko).

I think/hope implementing/converting those into libpeas plugins should
give you the opportunity to discover things you might not have
considered and to figure out solutions. Because something I would like
to avoid is landing a bunch of changes and then going "oops" that won't
work. :)

Once those are fully functioning locally (your repo), then let's see
how ginormous a change it is and decide if we should merge it upstream
as a single commit, or broken up into a few.

Does that make sense?

Thanks again!
--joanie



_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]