Re: Proposed Orca Migration

[Willie Walker <William Walker Sun COM>]

Thanks Shaun!  

Just to confirm: you are on board with the proposed solution for GNOME
2.16 as outlined in the discussion and implemented by the patches for
bug 348630 and bug 348643?

For GNOME 2.18, a task will be to to a better job on setting
accessibility preferences.  The Ubuntu folks have done some related
thinking: https://wiki.ubuntu.com/Accessibility/Specs/CommonATConfig.

Will

On Wed, 2006-07-26 at 12:04 -0500, Shaun McCance wrote:
> On Wed, 2006-07-26 at 16:34 +0100, Bill Haneman wrote:
> > On Wed, 2006-07-26 at 16:14, Shaun McCance wrote:
> > > On Wed, 2006-07-26 at 05:26 -0400, Willie Walker wrote:
> > > > Hi All:
> > > > 
> > > > In the spirit of keeping the Orca migration decoupled from the
> > > > accessibility properties dialog redesign, Bill Haneman has created
> > > > patches for control-center and gnome-session:
> > > > 
> > > > http://bugzilla.gnome.org/show_bug.cgi?id=348630 (control-center)
> > > > http://bugzilla.gnome.org/show_bug.cgi?id=348643 (gnome-session)
> > > > 
> > > > The first patch (control-center) gives preference to using 'orca'
> > for
> > > > the exec_ats property if screen reading or magnification is
> > desired, but
> > > > will fallback to 'gnopernicus' if 'orca' is not present on the
> > machine.
> > > > 
> > > > The second patch (gnome-session) will fallback to 'orca' if the
> > exec_ats
> > > > prefs has specified 'gnopernicus' but 'gnopernicus' is not present
> > on
> > > > the machine.
> > > > 
> > > > These seem to address Shaun's migration concerns as well as
> > Matthias'
> > > > FC6 concerns.
> > > > 
> > > > I'll be happy to work with the control-center and gnome-session
> > > > maintainers to roll these patches in for GNOME 2.16.
> > > > 
> > > > Comments?
> > > 
> > > I have only one concern with this proposal, and note that none
> > > of my previous proposals addressed this issue very well either.
> > > If I'm running different versions of Gnome off the same home
> > > directory, and I turn on the screen reader in the 2.16 desktop,
> > > my 2.14 desktop won't be able to launch the screen reader.
> > 
> > Will and I have talked about this case.  Our conclusion is that users
> > will not want to switch between gnopernicus and orca.  Besides, the
> > case
> > you are referring to is actually a sort of "forward compatibility"
> > scenario which one can never really support, i.e. a 2.16 dialog
> > enables
> > a feature not available in 2.14.  It also begs the question of why an
> > existing Gnome 2.14 would need a screenreader in 2.16 without having
> > enabled it previously, in 2.14.
> 
> On the NFS-using network I'm on at work, I do most of my work
> on my own personal machine, which I keep fairly current.  So
> generally, I change my settings on that machine.  Occasionally,
> I have to use another machine, and most Gnome boxes around the
> office aren't as current as mine.
> 
> If a new Gnome user joined the company in about six months or
> so, that user would probably get a 2.16 desktop and set all of
> his settings there.
> 
> > Three solutions are available to the user of 2.14+2.16 shared
> > directories who actually runs the 2.16 dialog and enables automatic
> > orca
> > startup:
> > 1) install orca on the 2.14 desktop, where it should run fine;
> > 2) use gnopernicus on both (with fallback to 'orca' on the 2.16
> > system,
> > if gnopernicus is not available);
> > 3) ln -s /usr/bin/orca /usr/bin/gnopernicus on the 2.14 system.
> 
> Yeah, all right.  I suppose there probably isn't a magical
> solution that doesn't suck somewhere.  So let's just bite
> the bullet and do this.
> 
> > > Situations like this are why it's nice to categorize the tools.
> > > It makes it easier to write forwards-compatible code.  Not that
> > > we could change past release now anyway.
> > 
> > Well, we could patch 2.14.X  but I don't think that these hypothetical
> > cases will actually have a serious impact on users (and in any case we
> > have straightforward workarounds).  Forwards-compatibility is tricky
> > at
> > the best of times.
> 
> That it is, and I do think we should put some serious effort
> into addressing it desktop-wide.  Probably a lot of smartness
> could be built into our configuration system to handle most
> cases.  But part of the problem is that developers just need
> to think about new interfaces they introduce (configuration
> keys, binary names, command line options, etc.) and how they
> will hold up to future changes.  It's not easy, and we won't
> always be able to predict the problems of the future.  But
> right now, I don't think we're even trying.
> 
> --
> Shaun
> 
>