Re: Proposed Orca Migration

[Willie Walker <William Walker Sun COM>]

Hi Shaun:

I think we've all agreed that we want to replace Gnopernicus with Orca
and I think we all agree that the accessibility dialog needs work.  I do
not believe the work for the two must be coupled.

If I understand your primary concern with the migration, it's that the
user who has configured their system to use a screen reader should
continue to have a screen reader after an upgrade to GNOME 2.16.
Furthermore, a user sharing their home directory between pre-GNOME-2.16
and GNOME-2.16 systems should get expected results.

I'd like to make two alternative proposals that should hopefully address
this concern with minimal impact.  The goal of each proposal is to
address the problem of replacing Gnopernicus with Orca for GNOME 2.16,
leaving the separate problem of redesigning the assistive technology
dialog for another day (GNOME 2.18).

BACKGROUND:
-----------

Based upon this e-mail thread and some digging around the code, here's
what it looks like the current model is for launching assistive
technologies:

1) The gconf setting for which assistive technologies to use is
/desktop/gnome/accessibility/startup/exec_ats, which is a list of names
of executables for assistive technologies to be spawned by
gnome-session.

2) The gnome-at-properties application, which is the one that brings up
the dialog for which you proposed modifications, writes the exec_ats
property.  The code for it is in the following file, which has various
hardcodings to things like gnopernicus and gok, and also has special
code to handle cases such as the screen reader also being a magnifier
(e.g., launch gnopernicus if the user selected either the screen reader
or magnifier, and only launch it once):

gnome-control-center/capplets/accessibility/at-properties/at-startup-session.c.

3) gnome-session/gnome-session/gsm-at-startup.c reads the exec_ats
property and just spawns off processes for each entry it finds.

PROPOSAL #1:
------------

Merely modify gsm-at-startup.c:gsm_assistive_tech_exec to see if the
exec string is 'gnopernicus'.  If it is, substitute it with 'orca'.

Here's how this would work - exec_ats would always still refer to
gnopernicus.  On pre-GNOME-2.16 systems which still have Gnopernicus,
gnopernicus would be run.  On GNOME-2.16 systems, where Orca has
replaced Gnopernicus, orca would be run.  Furthermore, using the
gnome-at-properties application to make AT startup preferences on any
system using either the pre-GNOME-2.16 or GNOME-2.16 would have the
desired effect both forwards and backwards.

The only thing that would not happen here is that Orca would read
Gnopernicus settings.  Our user base does not seem to be clamoring for
this seamless migration (we've not had one request).  If it is deemed a
necessity, however, we could work on code to suck Gnopernicus settings
into Orca when Orca is first run.

The documentation and release notes for GNOME 2.16 would also need to
remind users that when they log in for the first time on a GNOME 2.16
using a home directory that has been preserved from a pre-GNOME 2.16
install, Orca will be launched instead of Gnopernicus and Orca will
automatically bring up a configuration GUI for them to set up Orca.  

PROPOSAL #2:
------------

Cut everything out of the dialog except for the checkbox to enable
assistive technology support.  Point users to the other mechanism that
GNOME has for automatically starting applications when the user logs in:
the "Startup Programs" of the gnome-sessions-properties application.
This greatly simplifies the problem overall, reducing the need to
squabble over classifications of things such screen readers vs.
magnifiers, on screen keyboards vs. alternative input mechanisms, etc.

Will

On Mon, 2006-07-24 at 13:20 -0500, 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.
> 
> 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
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list