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

[Mike Gorse <mgorse alum wpi edu>]

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