I have my home directory on NFS and I use gnome from different machines
(and in VNC sessions) that have screens with different resolutions and
other differences. It would be _really_ nice to tell gnome that my
confugiration should be saved on per-DISPLAY basis instead of globally.
There is a planned fix for this in the next major revision of GNOME (2.0) which
will probably appear in the first half of next year. There's no good way
to retrofit it to the current version of GNOME however.
Thinking about it, as a bad hack you could make ~/.gnome and ~/.gnome_private
symlinks that get moved to reflect the hostname when you log in, but it
isn't going to be very satisfactory.
That what I was thinking - is there some central place in Gnome libs that
defines ~/.gnome? What about ~/.sawfish? I believe the easiest way to fix the
problem is to change those places so that I could use an environment variable to
overwrite those directories. Of course, I could just redefine $HOME, but that
would break to much other programs...
I have the patches to gnome-1.2 you need to do per display gnome configuration.
It does all of the settings so shares less than you might like (eg calendar
data!). They may go into 1.4 in some form but if you want them now email me and
I'll send you the patch
I was thinking - a part of what I really want is a way to make sure that I have
a separate Gnome session configuration per display size. But everything else
(including things like calendar and mouse focus type) should stay the same. So
somebody should decide, what kind of setting it would make sense to share, what
should be tied to display size and what should be tied to DISPLAY variable. Of
course, some of the choises should be user-controlled, but a sensible default is
Right, the sensible default and correct behavior will come with full GConf
deployment, probably not until GNOME 2.0 though GNOME 1.4 will contain
GConf usage for some applications. In GNOME 2.0 we will finally be able to
re-enable support for multiple sessions, since GConf will allow them to be
handled sanely. Anyway as far as I'm concerned this bug will get fixed in GNOME
2.0, because I don't think the "hack display name into .gnome path" solution is
really a solution for most users, though some hack-oriented users may find it a
This is a large-scale change affecting all gnome apps, not something we will fix
on the RH level (we are working on it upstream in the GNOME Project though)