Shaun McCance wrote: > On Thu, 2006-07-20 at 13:52 -0500, Shaun McCance wrote: > >> Yikes, all right. We should definitely keep the exec_ats key >> for legacy. I suppose the Assistive Technology Preferences >> dialog should continue to set the old values, if possible, >> to keep older machines functioning the same. >> >> I'm not sure what keys are used by the Preferred Applications >> dialog. The keys under /desktop/gnome/applications seem to be >> obsolete. We could just make six keys: a boolean to enable >> each technology, and an exec string for each technology. >> >> Then there's the question of the interface. Would we want to >> shunt stuff off to the Preferred Applications dialog? I think >> it will be more obvious if it's right in the Assistive Technology >> Preferences dialog. So something like >> > > I meant to say something else here, but forgot about it. > What happens if I set my preferred screen reader to Orca > on a fancy new machine, and then try to log into an older > Gnome using the same home directory. We don't have any > sort of fallback mechanism in place. > > This problem isn't unique to us, by the way, and it goes as > far back as networked Unix itself. Changing your shell, for > example, can be a real headache on a heterogeneous network > with centrally-managed login information. You won't even be > able to log into a machine without your selected shell. > > I don't necessarily have a good solution to this problem. > I can think of some strategies, but none that I think are > much more than a hack. > > I know there's been blue-sky talk of a next-generation > configuration system. A general-purpose solution to > problems like these would be a definite selling point > for such a system. > > -- > Shaun > > > _______________________________________________ > desktop-devel-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > This is one of my biggest headaches in supporting enterprise GNOME users. Consider these use cases:
1. An ISV creates creates a custom application and wisely chooses to base this application on GNOME components which won't change between releases. He creates a launcher for this application in the main menu. The launcher stops working when GNOME is upgraded. Not a huge problem for a developer on his laptop, a major headache for a sysadmin of 5,000 desktops. 2. Someone logs into a server running GNOME 2.1X, logs out and logs into a server running GNOME 2.1.X+2 using the same NFS home directory. 3. Someone logs into a server running GNOME 2.1.X, _doesn't_ log out and logs into a server running GNOME 2.1.X+2 using the same NFS home directory. (This can be common on Sun Ray and possibly other thin client GNOMEs) Should we say that cases 1-3 won't be supported by GNOME? or... A simple but incomplete and probably slow solution (hack?) might be to put the entire home directory under CVS control or on top of a versioning filesystem and give gdm and gnome session the smarts to checkout the right branch during login. Would something like this work instead?: Move everything off the filesystem into the filesystem independent configuration database. (this includes .gaim, .evolution, .gimp,.mozilla, font stuff, desktop files... which means the configuration database shouldn't be slower than the filesystem.) The configuration system manages configuration objects which expose read/write methods based on release, key and migration rules. E.G. Key :Range :Rule default_screenreader:2.10-2.14:RW default_screenreader:2.06-2.14:R default_screenreader:2.16-2.20:M The M rule means the migrate methods would be called for releases where Read or Write are not already defined in the rules. These methods would take key, version_key and version_now. In this case, the migrate read method would decide that if default_screenreader GNOME 2.12 key value is "gnopernicus", and the client is version 2.16, it returns "orca". Yeah, I know this idea is only 25% baked, but could it be refined into something which would improve the user experience? _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
