Re: Migration Paths for New Modules

[Bill Haneman <Bill Haneman Sun COM>]

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.

regards

Bill

> I'm not entirely sure about this either, and I'm not sure who's
> responsible for this.  Looking at the accessibility preferences,
> I see the following label on this machine:
> 
>   No Assistive Technology is available on your system.  The
>   'gok' package must be installed in order to get on-screen
>   keyboard support, and the 'gnopernicus' package must be
>   installed for screenreading and magnifying capabilities.
> 
> (Why isn't that label selectable?  And who thought that
> "screenreading" is a word?  It's two words, except that
> it's a compound adjective in this case, so it should be
> hyphenated.)
> 
> With a label like that, it seems to me that the tools are
> hard-coded somewhere.  That capplet, at least, is found
> inside control-center, but I don't know what module is
> responsible for actually launching the screen reader.
> 
> > If there is a real world use case for why importing Gnopernicus settings
> > is a necessity, however, we can look at importing them.
> > 
> > > How will her settings inter-operate with Gnopernicus if she
> > > has multiple machines using the same home directory?  
> > 
> > The settings for the two are completely separate at the moment.  I'd
> > really hesitate trying to combine them.  It could get rather ugly and
> > might screw the user more easily than keeping them separate.
> 
> I wouldn't necessarily worry about Gnopernicus's and Orca's
> settings.  What I'm worried about is if we have a GConf
> setting under /desktop/gnome for which accessibility tools
> to use, and how to launch them.  Selecting Orca on a system
> with Orca could then seriously mess up an older system, if
> we're not careful about the implementation.
> 
> This isn't necessarily something the Orca team needs to
> concern itself with.  Rather, it's something we need to
> deal with in whatever desktop modules glue this together.
> 
> --
> Shaun
> 
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Wed, 19 Jul 2006 15:21:55 -0400
> From: "Luis Villa" <luis villa gmail com>
> Subject: Re: Mummy, I made a platform in my pants! [Was: focus!]
> To: "Alex Graveley" <alex beatniksoftware com>
> Cc: Federico Mena Quintero <federico ximian com>,	Jeff Waugh
> 	<jdub perkypants org>, desktop-devel-list gnome org
> Message-ID:
> 	<2cb10c440607191221m6a4ee43dk79e3cda7051004b3 mail gmail com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 7/19/06, Alex Graveley <alex beatniksoftware com> wrote:
> >
> > Respectfully, I don't agree.  There is a big set of missing frameworks
> > that stops rich interop in Gnome applications, and generally make
> > applications much harder to write well.  All other desktop platforms
> > include at least a subset of these...
> >
> > * Document framework
> > Provides document loading/saving/printing/etc abstractions, window/tab
> > management, automatic recently used, scripting hooks, etc.
> >
> > * Scripting framework
> > Allows apps to easily expose external scripting and event notification.
> >   D-BUS was the big missing piece here.  Can specify sets of interfaces
> > for common tasks that apps can implement, and building up the frameworks
> > to provide useful default implementations.
> >
> > * Rich Extension/Plugin framework
> > Common UI for installing/removing plugins and checking for updates and
> > downloading, common hooks for menu/toolbar integration and UI event
> > integration.
> >
> > * Undo framework
> > Almost no applications in Gnome support good Undo.  Should provide both
> >   reliable desktop-wide interaction for text widgets as well as at an
> > abstract object level.
> >
> > * Rich DND/CopyPaste framework
> > Undocumented DND targets, poor support, and manual data parsing abound
> > in our applications.  Could provide structured data interop to make
> > doing this loads easier.
> >
> > * Persistence framework
> > Saving and indexing application-internal data, optionally exposing to
> > search engines like beagle.
> 
> I'd add:
> 
> * collaboration framework (though maybe the Abi guys are pushing in
> this direction in a way we can all use)
> 
> * web integration framework- we know that MS is going to make all
> their apps backend to various web services in the not-too-far future,
> and we know that we can make our apps much more compelling if (for
> example) f-spot integrated seamlessly with web-based picture sharing,
> or gourmet integrated seamlessly with web-based recipe sharing.
> 
> * search framework.
> 
> Luis
> 
> 
> ------------------------------
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
> End of desktop-devel-list Digest, Vol 27, Issue 74
> **************************************************