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
Howdy Joanie, Howdy List,
I just did some more work the last days. Just a small update what i did.
- 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).
- A simple API helper class what supports me a little with a useful functions library.
- 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
- 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.
- 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