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

[Joanmarie Diggs <jdiggs igalia com>]

Hey Chris.

The reason I think we want to at least explore settings and associated
GUI is to ensure that this plugin approach works as we expect. Even if
we don't initially land the plugins with settings and GUI already
handled, seeing a proof of concept that demonstrates things (will) work
for those plugins would make me feel a lot better.

That said, hammering away seems like the right first step. Thanks
again!
--joanie

On Sat, 2021-06-05 at 21:35 +0200, 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 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