GNOME.org
 

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

Agree... Couldn't we create an Orca class that contains all of (or most of) its features, then for each 
feature, have a method plugin devs can make use of? EX: Orca.TimeAndDate, or Orca.FocusedObject.Location?

-----Original Message-----
From: orca-list <orca-list-bounces gnome org> On Behalf Of chrys
Sent: Saturday, June 5, 2021 7:21 PM
To: orca-list gnome org
Subject: Re: [orca-list] Pluginsystem for Orca using libpeas

Howdy Andy,

sounds resonable to me,
point 2. is in fact the biggest issue i currently have. there is no "orca" class what is getting instanced. 
they way things getting referred is somewhat mystical and strange to me. its all a very mixture of procedural 
programming and object orientation.


Am 05.06.21 um 22:07 schrieb Andy Borka via orca-list:

I would like to see a few things to get started:

1. An API object that represents the currently focused object 2. An 
object that represents the current running instance of Orca 3. The 
ability to return the currently focused object's size/location.

There are a bunch of things for that to happen like getting the accessibility tree nodes since we need to 
know who the parents, children, and siblings of the focused object. We should also let Orca set focus to 
objects that currently don't allow it, such as those where isfocusable state is false.


-----Original Message-----
From: orca-list <orca-list-bounces gnome org> On Behalf Of Linux A11y
Sent: Saturday, June 5, 2021 3:35 PM
To: Joanmarie Diggs <jdiggs igalia com>
Cc: orca-list <orca-list gnome org>
Subject: Re: [orca-list] Pluginsystem for Orca using libpeas

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

_______________________________________________
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



_______________________________________________
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]