Re: Migration Paths for New Modules

[Shaun McCance <shaunm gnome org>]

On Thu, 2006-07-20 at 18:59 +0100, Bill Haneman wrote:
> Shaun wrote:
> > On Wed, 2006-07-19 at 14:03 -0400, Willie Walker wrote:
> > > A big question for me is what does it mean to be 'the screen reader' and
> > > how does it get launched (much like what it means to be 'the web
> > > browser' or 'the e-mail reader')?  This is something outside of the
> > > control of Gnopernicus and Orca, and I'm not sure how this works.
> > > Guidance here would be greatly appreciated.
> 
> The current behavior is partly hard-wired; there is a gconf key called
> /desktop/gnome/accessibility/startup/exec_ats which is used to launch
> more or more assistive technologies at startup. (IIRC it's a
> semicolon-delimited string).
> 
> However the AT Prefs dialog, which has the 'screenreader', 'magnifier',
> and 'onscreen keyboard' checkboxes, currently has hard-wired behavior;
> if you tick the 'screen reader' box, it parses the above string and
> ensures that 'gnopernicus' is included in the exec_ats string.
> 
> This is of course not the right way to do it, but at the time the idea
> that there would be multiple screenreaders/etc. was not something that
> the gnome-session maintainers or UI folks wanted to deal with (after
> all, we only have one panel and one officially-blessed email client,
> etc. etc.).
> 
> However I think now would be a good time to fix this.  I see several
> possible solutions:
> 
> 1) keep the exec_ats string as-is, using it for legacy behavior, but
> associate the checkboxes with boolean gconf keys.  Then gnome-session
> could read the 'screenreader' gconf key and launch orca automatically if
> it were checked (same for 'magnifier' gconf key, with different params
> passed to orca).
> 
> 2) modify the exec_ats string the next time the user runs the AT prefs
> dialog, warning the user of the change.  User can cancel and leave
> exec_ats as-is.
> 
> 3) Do both #1 and #2 above, i.e. add new gconf booleans and offer to
> change the startup ats (via modifying exec_ats) when the user first runs
> the AT support dialog.  We could also launch the AT support dialog
> automatically if exec_ats is not empty, to inform the user of the
> replacement of gnopernicus with orca.
> 
> Perhaps it would be appropriate to add 'screen reader', 'magnifier' and
> 'onscreen keyboard' (or 'keyboard alternative'?) to the
> /desktop/gnome/applications directory and the Preferred Applications
> dialog so that the user could configure which AT they wanted to do a
> specific job (with orca the new default screen reader).  This would also
> make it easy for users to select dasher instead of gok, for instance.

Yikes, all right.  We should definitely keep the exec_ats key
for legacy.  I suppose the Assistive Technology Preferences
dialog should continue to set the old values, if possible,
to keep older machines functioning the same.

I'm not sure what keys are used by the Preferred Applications
dialog.  The keys under /desktop/gnome/applications seem to be
obsolete.  We could just make six keys: a boolean to enable
each technology, and an exec string for each technology.

Then there's the question of the interface.  Would we want to
shunt stuff off to the Preferred Applications dialog?  I think
it will be more obvious if it's right in the Assistive Technology
Preferences dialog.  So something like

  [ ] Screen reader
      Select: [__ Orca __]
  [ ] Magnifier
      Select: [__ Gnopernicus __]
  [ ] On-screen keyboard
      Select: [__ GOK __]

If each AT installs a .desktop file, we could have a special
key that indicates what sort of AT it is, like:

  [Desktop Entry]
  Encoding=UTF-8
  Name=On-Screen Keyboard
  Comment=The GNOME On-screen Keyboard
  Exec=gok
  Terminal=false
  Type=Application
  Icon=gok.png
  Categories=Application;Accessibility;
  X-GNOME-AT-Type=on-screen-keyboard

Then we could actually present a drop-down with choices.
Maybe we still need a "Custom" with a text area for the
exec string.  The Preferred Applications dialog allows
that.  And that would make the above interface uglier.
We'd probably want a way to pack in a warning label
for each checkbox when you don't have any known ATs
installed for that type.

I'm just tossing out suggestions.  Input is welcome.

--
Shaun