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