On Mon, 2006-07-24 at 19:20, Shaun McCance wrote:
> 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.
gnome-session (see gsm-at-startup.c)
> 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.
Not sure what you mean by this; you mean parse the existing exec_ats
string and poke the gnopernicus gconf keys to see if magnification is
on, etc?
I would suggest that instead of that, we
1) check to see if exec_ats is non-empty, meaning that ATs were selected
in the old user env;
2) if so, auto-launch the AT Properties Dialog (using the old ATs, of
course), and post a short ALERT dialog offering to migrate the user.
> 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.
Otherwise this sounds good to me.
> 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
>
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
