Bug 217730 - gnome-panel (and gnome-session) "too connected" to user instead of to session
Summary: gnome-panel (and gnome-session) "too connected" to user instead of to session
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-panel   
(Show other bugs)
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-11-29 17:36 UTC by Eli Barzilay
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-29 21:28:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Eli Barzilay 2006-11-29 17:36:40 UTC
Description of problem:

Version-Release number of selected component (if applicable):
* gnome-panel-2.16.1-3.fc6
* gnome-session-2.16.0-3.fc6

How reproducible:
* Always

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
Actual results:
* 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.

Expected results:
* 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.

Additional info:
* I'm using Sawfish, but that doesn't seem to be the problem.

Comment 1 Ray Strode [halfline] 2006-11-29 21:28:27 UTC
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.

Comment 2 Eli Barzilay 2006-11-30 06:44:23 UTC
Creating two users is a non solution.  I tried something similar:

  HOME=~/.vnc gnome-session

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.

Three notes:

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.

Comment 3 Ray Strode [halfline] 2006-11-30 15:13:56 UTC
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.

Comment 4 Eli Barzilay 2006-11-30 17:34:27 UTC
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

Note You need to log in before you can comment on or make changes to this bug.