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
Attachment:
at-support.png
Description: PNG image