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
>
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
