Re: Proposed Orca Migration

[Shaun McCance <shaunm gnome org>]

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