[g-a-devel] Refactoring Orca to be less GUI/DE independant.
- From: Luke Yelavich <luke yelavich canonical com>
- To: gnome-accessibility-devel <gnome-accessibility-devel gnome org>
- Subject: [g-a-devel] Refactoring Orca to be less GUI/DE independant.
- Date: Fri, 30 Aug 2013 22:40:50 +1000
Hey folks,
I originally intended to raise this at the most recent a11y meeting, however due to my own carelessness, I
ended up missing that meeting, my apologies.
I'm going to be working towards getting some form of screen reader accessibility into the Ubuntu touch 14.04
release. THis is a release that will be usable on all currently available nexus devices, and will be a base
for phone vendors to release phones using Ubuntu.
As we all know, Orca currently uses GTK rather heavily, mostly for its preferences window, but also for
visually indicating flat review cursor location on screen, and there may be more which I am not currently
aware of. The Ubuntu touch release will not be shipping with GTK, nor X, and will be using Qt, and Mir, a
Canonical developed display technology, similar to Wayland.
In addition, it will be necessary to write some form of configuration UI, which will be integrated into the
Ubuntu touch main system settings application, as part of the accessibility settings panel. So it will also
be necessary to expose some form of interface to allow Orca's configuration to be changed, and to be done so
whilst Orca is running. I know this has somewhat been on the Orca roadmap for a while, given the desire to
ship Orca configuration as part of GNOME control center.
I'm aware that Orca stores its configuration in a json file, so one solution could be to use a json library
to write out the config file, but should Orca change its configuration storage in the future, this would mean
much code needing to be rewritten. My thought is that we could move Orca's configuration management into a
GObject introspected
library, which Orca itself could use, and which would be easily consumable by anybody else who wanted to
write Orca's configuration. The library could also assist with the process of signalling a running Orca to
reload its config, most probably DBus.
I'll be able to assist with whatever solution is eventually agreed upon, so actually getting the work done is
not likely to be a problem.
I'd appreciate people's thoughts or suggestions should they have any better ideas.
Luke
[
Date Prev][
Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]