Re: [orca-list] Status update for Orcas new Plugin System Level 1



Howdy Rastislav,

thanks! Words like that motivates me to continue :). I like when work is respected by others and i like it to work together with cool people 8-).

You are right. Its currently very hard to extend or provide new functionality even there is the customization.py.  No hooks, no clear internal structures, no interfaces an mystical API. Maybe Joanie is the only one person who understands all the internal stuff ( really espect for that). I took very long to understand things til i was able to start this work. My first attempt was SOPS to improve that situation. (I brought all for me known useful parts together in that slice of code). Its a taff learning curve if you just do that in some spare time :). At least for me.   So i m open minded to every good  idea and hope for every help we get. I bet making it more  easy to understand the API and internals will bring more support and contributions by the community. 

As NVDA already provides an similar way, maybe some code code could be reused and a collaborative relationship between the communitys could provide a win win situation for all. The a11y community is very small comparing to others. So everything matters here. I see this. And i hope do this huge rework will make us ready for future..

Yor idea sounds quite reasonable to me. Maybe its a good way to start sharing ideas and code. I like your idea. If i provide the required interfaces for you, would you be able to migrate the NVDA mathProvider to GTK and orca?

Mature all this to be stable and clean will take a while. But i would go that way with help of the community and hope for any help i get :).

Thanks again for some warm words.

Cheers chrys

Am 10.06.2021 um 00:32 schrieb Rastislav Kish via orca-list <orca-list gnome org>:



Hey there,

first of all, @Chris & @Joanie, this is really awesome!

I'm really happy to hear things may be finally getting to move here, as the Orca's plugin system and overall composition was... Let's say not very friendly for extending.

I'm also happy that there is a common initiative for this, when I first saw Chris' post about a new plugin system for Orca, knowing how deep these things usually cut into the code, I was seriously affraid about different opinions on a longterm change burying the whole stuff.


I'm really looking forward to see where this goes.


Now, to a more practical tone.


I know refactoring is a really hard work, which requires great attention and oversight to not break any of the already existing functions.

But still, when you're already working on it...

May I suggest a slight change in the way of processing Math in Orca?


Let's take NVDA as an example. In NVDA, there is a basic MathProvider class, which is used to process MathML on websites. When detecting a math object, NVDA simply calls an instance of MathProvider with the MathML code to get its textual representation, which is then used as the on-page description.

When the user finds the Math object and activates it, NVDA again calls MathProvider instance with the MathML code now to display a window where the user can browse the _expression_ in a tree like hierarchy.


This way, it's quite easy to implement various mathematical backends by simply deriving mathProvider, which is abstract if I remember right.


For example, my MathPresenter is basically a daemon, listening currently on a TCP port, expecting requests for converting MathML to text and displaying MathML in a window. Currently, a script in my browser takes all Math objects from a loaded webpage and sends them to the server for translation, results of which are then represented as buttons replacing the original Math objects.

When a user clicks on one of the buttons, the script performs a display request to the server, which handles everything necessary.


This works quite well, but the disadvantage is, that the original Math objects are lost and sighted reviewers thus can't see the formulas, just the buttons.


If Orca had a MathProvider class like NVDA, the browser part would no longer be necessary, and everything could be handled in the screenreader (I mean everything related to the communication with user and server, the MathML to text and MathML tree display would still be handled by the server of course).


I know there is a lot of work to be done on Orca with the reformatting and that already existing features have the priority right now, and I fully encourage you to keep the great job.

You just might keep this possible change in mind while developing the structure, so we can move forward even in the area of mathematics.


Thanks!


Best regards


Rastislav


Dňa 8. 6. 2021 o 15:24 chrys napísal(a):

Howdy Joanie, Howdy List,

I just did some more work the last days. Just a small update what i did.

  1. I created a new class "orca" in orca.py. this should represent the applications main class in mid term future. We should move all "global" functionality into this to have an entry point for references for our plugins (like already suggested by Andy Borka). I already added some API for signal handling and dynamic storage of objects. last is currently used to have some "compatibility" and keeps all of orcas internal stuff. this should be moved step by step to "real" objects. The handling of dynamic objects is there to register stuff by plugins what could be used by others (as libpeas supports dependencies in plugins, this could be very useful).
  2. A simple API helper class what supports me a little with a useful functions library.
  3. Time Plugin: Works! but it currently uses an hard coded shortcut. the binding API of orca is not very friendly to consume. i still have to figure how to get shortcuts for given functionality with loop through list every time. I will come up with some nice compatibility solution here. The User settings of Time is already respected as expected. the shortcut is the default one Orca + t. I removed the build-in functionality completely
  4. Date Plugin: same situation as for time (hard coded shortcut, user settings respected). the double tap  shortcut (pressing t two times fast Orca + t) works here as well.
  5. Mouse Review: Works! japp, it reads the object below the mouse pointer for me :)! i completely removed the build-in functionality. It for some quirks in the default.py and web/script_utilities.py are solved by the dynamic API usage. but the plugin is optional. if its not loaded, the stuff still works as expect. i reused almost all the code with some kind of compatibility replace global import of modules by have global variables set by the plugin activation. it respect the settings on startup. toggle shortcut is registered :) but hard coded to orca + e.

whats missing (well, as expected, as we wanna take that in an next step):

  • the settings are mostly respected but the keybinding definition stuff.
  • any UI handling

@Joanie, let me clean up some stuff then we could take a look at it and take the next step.

cheers chrys

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