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. 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. > 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. Bill > -- > Shaun > > _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
