GNOME.org
 

Re: Proposed Orca Migration

Hi Sean, Will,
If I might chime in... I think either of Will's proposals is fine for GNOME 2.16, with a slight preference to #2 - to move users to launching AT at startup just like the launch other apps at startup.
Calling out "screen reader", "screen magnifier", and "on screen keyboard" does nice things for visibility, but it oddly suggests those are the only three kinds of AT. As has already been noted, Dasher isn't exactly an "on screen keyboard". Certainly Dasher users might want to have it started automatically at login. Folks who have their computer talk for them (a use the latest Dasher can be put to, as well as KMouth from the KDE accessibility community) might want that device always launched - especially folks for whom a main use of their computer is as their (audio) communication device. Also the KDE KMouseTool app that is a mouse substitute is another "possible launch at startup" AT - which again doesn't fit into our three existing categories. Looking outside of the UNIX desktop world, there are several additional flavors of apps used for accessibility in Windows & Macintosh. And finally, we've already observed with both Gnopernicus and Orca - we have one app that does both magnification & screen reading; so why have a GUI that suggests they are different?
For GNOME 2.18, I think we should look at a user interaction session (I had the term "wizard") to determine how the user wants his/her desktop configured to best meet their needs - including but not limited to automatically launching assistive technologies. 

Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


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


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]