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



Confirmed.
Thanks.

On 7/2/21 2:24 PM, chrys wrote:
howdy José,

the issues should be fixed now. please pull again. all plugins should be activated by on ora start again.

cheers chrys

Am 02.07.21 um 18:18 schrieb Linux A11y:
Howdy vilmar,

Ah, hehe you are right. I disabled some plugins for testing purposes to try the activation in plugin manager. I bet i forgot to enable them all by default again before pushing.

Let me fix this up after having dinner. ~30 - 60 minutes.

Cheers chrys

Am 02.07.2021 um 15:46 schrieb José Vilmar Estácio de Souza <vilmar informal com br>:

Hi Chrys.
Today I updated the orca from the version that implements the plugins and noticed that some shortcut keys lost their function. When I press for example capslock+t the time is not announced, but if I press the same sequence twice, the date is announced.
Thanks.

On 6/6/21 12:36 PM, chrys wrote:
the work is currently located at:
https://github.com/chrys87/orca-plugin/

just use the main branch. send me your github login, so i can give you write permission if wanted.

after install the dependencies you need to run
./autogen.sh
./configure
make
sudo make install

that's just it.

i just got the date and time announcement plugins up and running. they already respect the user settings. currently try to figure how to connect them to the already existing shortcuts. currently they connect to an hard coded shortcut by their own (what works). but wanna have them adopted to the given keyboard settings to give some level of compatibility as i don't want to start too many construction zones until we wire up some some nice settings management.
once this is done i try myself on the mouse_review stuff.

but time for dinner now :).

Am 06.06.21 um 16:27 schrieb Andy Borka via orca-list:
Sure. I have to get my Ubuntu environment up and running again. I got a new laptop that Ubuntu 21.04 didn't support at first. Now, looks like it supports it for the most part. Where is the repo so I can take a look and play around?


-----Original Message-----
From: orca-list <orca-list-bounces gnome org> On Behalf Of chrys
Sent: Sunday, June 6, 2021 10:16 AM
To: orca-list gnome org
Subject: Re: [orca-list] Pluginsystem for Orca using libpeas

Howdy Andy,

yea that could be the plan :). Wanna dive in and try starting this?

Am 06.06.21 um 02:07 schrieb Andy Borka via orca-list:
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

_______________________________________________
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

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