Re: Multi-sessioning for GNOME [revisited]

[Havoc Pennington <hp redhat com>]

Hi,

Moving .gnome around is not a solution. 

 - all settings should not be per-session. Some should be per-host, 
   some per-display, etc. If we want to be remotely user friendly
   GNOME should automatically decide which are which.
 - users do not want to know about .gnome or environment variables;
   these are command line details, not in end user awareness
 - .gnome is deprecated anyway

Making this usable will involve GConf and gnome-session work, along
with fixing applications when required, and probably would be enhanced
by multiple display support in GTK.

I think we should fix it properly, because these semi-fixes just make
it harder to support upgrades. For example, if you upgrade RH 6.2 to
7.0 it will go in .gnome and modify things so the upgrade goes smoothly.
If you are using these weird hacks it will just fall over. GConf gives
us an appropriate abstraction layer to avoid this type of problem in
the future. The upgrade path to 2.0 will be hard enough without adding
an infinite number of .gnome directories.

So our target here should be GNOME 2.0 and we should be thinking "get
it right." We have a semi-plan on how to support this from the GConf
side, and gnome-session needs a lot of enhancement all around (Owen
could elaborate there and probably has in the past).

For GConf, the basic idea we had, which I guess is in the thread Glynn
mentioned, is that we have a way for apps to install a hint "this
setting is per-display" or "this setting is per-session" or
whatever. Then, GConf would have a per-session storage backend that
gets the per-session settings. That's nice and simple, and works
properly.

I think gnome-session already more or less supports multiple sessions,
they are just disabled because of the .gnome problem. IIRC the needed
work on gnome-session is to enhance its ability to interface with a UI
(see Startup Programs control panel).

Havoc