Re: Migration Paths for New Modules

[Shaun McCance <shaunm gnome org>]

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