Red Hat Bugzilla – Bug 217730
gnome-panel (and gnome-session) "too connected" to user instead of to session
Last modified: 2007-11-30 17:11:50 EST
Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Log in as usual, with a plain Gnome environment
2. Create a panel that is not expanded, and have it on the bottom-right corner
of the screen
3. Start a VNC session with a smaller screen size
4. Run gnome-panel in the VNC session
5. Kill the VNC server
* As soon as gnome-panel runs in the VNC session, the bottom-right panel gets
placed correctly in its corner -- but the same panel on the console moves to
the same absolute position which is no longer in the corner. Moving the
console panel back to its corner works for a brief time and then it hops back
into the screen.
* When the VNC session is killed, the gnome-panel detects that and tries to
restart itself on the console session -- but because there is a panel running
there already, an error popup shows. The error popup needs a lot of
convincing to disappear.
* I would expect these Gnome components to behave better on multiple sessions
used by the same user. An ideal solution is to make it possible to run
several independent sessions, each with its own configuration.
* However, this may be too difficult since Gnome seems to be desigend for
maximum sharing of information for all user interfaces, so the above problems
could be fixed (easily?) with the current setup:
- Make the panel placement infer and use gravity correctly (so things that
are placed in the bottom-right part of the screen will use bottom-right
- When the X session that the panel is running on dies, the panel should not
try to restart itself on a different X session.
* I'm using Sawfish, but that doesn't seem to be the problem.
So we basically don't support this.
GDM will even give you a fat warning saying not to do it if you try to log in twice.
Is this something you could solve by creating two separate users, or going
System > Preferences > Remote Desktop
and sharing one session?
Another approach you might be able to get away with is some hack that has two
users in /etc/passwd with the same uid and different home dirs and usernames,
but I wouldn't recommend that.
Creating two users is a non solution. I tried something similar:
but this creates a huge mess. Every application that runs from the environment
uses the other home directory, and trying to make sense out of this mess
(copying some configurations, symlinking others) is hopeless.
Using the remote desktop thing doesn't work -- nothing is listening on the VNC
port, but if it's some FB-based VNC then these things are much slower than
a proper VNC session. Besides, I really do want a separate VNC -- one session
to work locally and one for remote work. I have different uses for each.
1. I described solutions for the two problems, which make sense *regardless*
of allowing multiple sessions -- both the use of gravity, and not showing
an error message when the panel is trying to restart itself on a different
screen (just in case some of us are crazy enough to have a panel on two X
2. Still, it is disappointing to hear this answer. I consider this an
unfortunate by-product of a bad design decision, which is bad in this case:
as bad as X might be, it has supported multiple sessions for decades. Now
this is a step back just because Gnome is trying it best to go down to the
level of commercial desktops.
3. I would much rather that the state of this bug is modified: I hope that the
local solutions I suggested make sense and if so it should be reopened;
otherwise please change it to WONTFIX, since the bug is definitely not
resolved so it is better to have it documented.
Why isn't creating two users a solution?
If you'd really like to see this support added, you can file upstream bugs for
individual problems (with patches hopefully).
note the bug is WONTFIX.
Creating two users seems like it can work:
- create a second user, copy over all .gnome* .gconf* etc to new user
- realize that there's a bunch of other stuff that you do want sharing for,
like shell dot files, .emacs etc -- so symlink them
- then see that all launchers start applications in the bogus home directory,
so change them all to use a meta `run-at-home' script that starts them with
the correct home directory
I went through these steps, and sorting out what should be copied and what
should be symlinked is a sure recipe for madness (for example, for proper
Gnome applications (not desktop widgets) you do want to share settings).
I can hear you now saying that there's no way to avoid marking which parts of
my environment should be shared and which should be separate -- but the line
is pretty clear: I *don't* want two separate users (otherwise I'd just use a
real second username) because I want to share most of my environment. I just
want the parts of this environment that deal with the graphical session to
use consider the session that it's using. Just like the fact that resizing
one xterm does not change the behavior of all other opened xterms. It's even
easy to do so -- instead of hooking configurations on "$USER", hook it on