Re: Proposed Orca Migration

[Bill Haneman <Bill Haneman Sun COM>]

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
>