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

[chrys <chrys linux-a11y org>]

Howdy Mike,

ah, i see. does this change in AT-SPI also mean that orca will be able 
to react in windows what does not implement ATK? this would be f***king 
awesome as the screenreader could provide useful tools to read the 
screen like OCR.

I think it doesn't touch me just right now, i hope i don't forget about 
as soon as it does :).

thanks for notice.


Am 05.06.21 um 22:06 schrieb Mike Gorse:
> 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