Doing Orca right in 2.16 will require some changes in core Gnome modules. Unfortunately, the feature and UI freeze is today. I'd like to outline a proposal for getting Orca in this release cycle.
First, I don't know which module is responsible for starting
accessibility tools on log in. Somebody must know.
The accessibility tools are currently stared in GConf in the
key /desktop/gnome/accessibility/startup/exec_ats. This key
is a list of tools to start.
I propose we add the following six keys:
enable_screen_reader (boolean)
enable_magnifier (boolean)
enable_on_screen_keyboard (boolean)
screen_reader_command (string)
magnifier_command (string)
on_screen_keyboard_command (string)
The enable_* keys simply toggle whether that particular
tool should be launched on log in. The *_command keys
provide what to exec to make it happen. When a user
first logs into a 2.16 desktop, we migrate the values
in exec_ats to the new keys. We could have a separate
key, exec_ats_migrated, that defaults to false and is
changed to true once the first-time migration has been
done. Maybe there's a less hackish solution.
Then, we modify the code that launches the ATs to read
from these new keys. Then, we modify the AT prefs tool
in control-center to set them, adding a means to specify
which program to use for each tool. I made a mockup of
the dialog in glade and attached a screenshot.
The mockup I've sent presumes we can get a list of the
appropriate programs. We can accomplish this with an
extra key or three in the applications' .desktop files.
We could either have one key that takes string values
from a controlled vocabulary ("magnifier", etc.), or
three boolean values for each tool type. I'm pretty
indifferent.
We then add those keys to Gnopernicus, GOK, Orca, and
Dasher. Then we pat ourselves on the back for a job
well done.
(Open issue: Bill suggested dropping the term "on-screen
keyboard", and I'm inclined to agree. That term really
only describes GOK. Dasher, and other potentially useful
programs in the future, are more generally "alternative
key entry programs". But that just sounds obtuse.)
Today being the feature and UI freeze, this proposal is
already up against a wall. But I've never let reality
stop me before. For what it's worth, I'm giving the
go-ahead for the UI change as the documentation leader.
My concrete, time-based proposal is this: We provide
provisional approval to go ahead with this course of
action, but we will not let it stretch way late into
our release cycle. We will require that these changes
be implemented by next Monday, July 31st, and that we
get new releases of the affected modules immediately.
(The big code changes, I'm not going to get all pissy
about Dasher adding a key to its desktop file.)
If it can't be done in a week, we revert, and we hold
off on Orca until 2.18. Though the changes are visible,
I don't think they're very difficult or high-risk.
I don't maintain any of the relevant modules here. I'm
just being an active cheerleader. We need to have good
cross-module cooperation for this to happen. Without
buy-in from all affected maintainers, we'll just have
to postpone.
--
Shaun
at-support.png
Description: PNG image
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
