[orca-devel] Strawman: Ramblings about orca, performance improvements, improving user interface.

[Luke Yelavich <themuso ubuntu com>]

Hi all,
For a while now, I have had a fair number of thoughts flying around in my head about orca, and a couple of things that could be done to improve it in some way. One of them is certainly doable, the other is probably something that won't ever be considered, but is something worth thinking about, at least I've been thinking about it, particularly in light of some discussions relating to LXDE and the lubuntu distro recently. The following is likely to get very rambly, so please feel free to reply if you want something clarrified.


Orca and its interface

So at the moment, we have the orca main window, with buttons to go into preferences, go to Orca help, and a button to quit Orca. This is fine. Users can choose to not show the Orca main window, so it doesn't get in the way. I am one who does so. I think since the 2.9 series of Orca, we have had the support of profiles in the Orca configuration. I am not one who personally uses this, but I am sure there are many users who do. Lets also dwell for a short time on other settings that are found in the bowels of the preferences window, things like word/key echo options, Braille and magnification, speech synth, etc.

What if we were to bring a small number of the most common preferences a little closer to the user interface wise, say either a legacy systray icon for those desktops who still use them, a notification panel or whatever they are called in GNOME shell, and in the case of Unity in Ubuntu, an indicator. This UI element for orca would present a few useful settings that users may want to change on the fly. The menu coule look something like this:
* Speech Settings
  * Speech Synthesizer
    * A list of available speech synthesizers is made available here
  * Person
    * A list of supported voices is made available here
  * Speech Preferences...
* Braille settings
  * Braile monitor (Check menu item)
  * Enable braille (Check menu item)
  * Braille Preferences...
* Magnification settings
  * Enable Magnifier (check menu item)
  * Magnifier Preferences...
* Switch profile
  * List of available profiles
* Preferences...
* Save settings
* Quit...

Thats a very rough outline, and there is certainly stuff there we could add/remove, but from a few minutes of going through the preferences and pulling a few things out, thats something to start with. Having options to go to speech/braille/mag preferences, would also jump you into the preferences window, and directly over to the relevant tab in the prefs, so you don't have to move through all those tabs just to get to what you want to change. If we were to create such a menu in gnome-shell/unity etc, we could also have an Orca shortcut key to jump to that menu, for users to make use of it.

I am well aware that this is pretty much what various Windows screen readers do, but from my experience, such a quick access interface works, and it works well. Say you want to change synths just to read particular text on a website/in a document in another language. At the moment, you have to load Orca prefs, move to the speech tab, find the speech synth/language, and change it. Then once you are done, you have to remember to set things back to how you usually want them. Switching synth stuff from a menu saves time, and its not saved into your settings unless you explicitly request it to be so.

I am no UI designer, so design wise this may be frowned upon, but I for one, would certainly make use of it if it were there.


Orca in ultra-light desktop environments, and overall performance

So Ubuntu has a derivative called Lubuntu, which is based on Ubuntu and the LXDE environment, which itself is based on GTK. They have recently been in contact with the Ubuntu accessibility team about how they could improve their accessibility. One thing that came up for discussion was the lowest system specs machine wise that they are aiming at, which is an i686 class CPU, with (I think) 192MB RAM, maybe less, CPU speed wise, probably around 200-250mHz, give or take. One point that was raised was that of Orca being written in Python. Orca itself being written in python is not a problem, however concerns were raised about the overhead of having to launch a python interpretor, and the overhead that may bring when having extra daemons plus communication between python code and everything else. I know myself that even on a dual celeron machine running at 466mHz with 768MB RAM, Orca with GNOME was a little sluggish. Granted GNOME is probably no longer aiming at that spec machine, but I found myself wondering whether using XFCE or something lighter would be any more performant.

I am not for one second knocking the benefits that using Python brings. Its easy to make a change and test, easy for new contributors to get involved, easy to write scripts for improving accessibility of apps, etc. I am also sure that the upstream python devs do everything that they can to make python as performant as possible. However, when it comes to doing something like iterating over a tree of at-spi objects in a window, and other things along similar lines, I wonder just how much more performant using a language like c would be, particularly where gobject introspection is concerned having to go back and forth accross language bounderies. Again, I am no expert on this kind of stuff, and I am aware that there is ongoing work to improve at-spi over dbus. I am also aware that the cons may outweigh the pros, particularly where performance itself is concerned, but I still think this is worth at least thinking about.

C of course is an option, but then there is all the GObject boiler plate code that needs to be written. Sure that in itself is also not really a problem, but that takes time. One compromise could be vala. I was told that recent vala developments have included a just in time compiler, i.e running as an interpretor, similar to python. I think this is still early days, but its being worked on. The main benefit of vala though is writing your app in vala, and then having that code compiled into GObject C, which can then be compiled. Vala also supports gobject introspection, which makes working with at-spi a breeze. It would also be possible to create gobject introspection bindings for application scripts, so that a user could still write an app script in python, and have it still work, although one small problem with that is actually launching a python environment to run sed scripts. This is one area I haven't really thought through.

Of course this is one thing that probably won't ever be considered, now that we are well down the python road, but strawman discussion is always good, and I dare say that if gobject introspection, vala etc were available when Orca was initially started, that direction may indeed have been taken.

Hope you have enjoyed the reading. I certainly think my first proposal is worth considering, and is certainly doable. Orca performance is something I am sure we are all aware of, and whilst rewriting is very likely out of the question due to lack of time/resources, its worth pondering whether having some parts of Orca written closer to the metal would at all be beneficial.

Thanks again for your time, and let the discussion flow. :)

Luke