Bug 217730
Summary: | gnome-panel (and gnome-session) "too connected" to user instead of to session | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Eli Barzilay <eli> |
Component: | gnome-panel | Assignee: | Ray Strode [halfline] <rstrode> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6 | CC: | davidz |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-11-29 21:28:27 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Eli Barzilay
2006-11-29 17:36:40 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 to 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: 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 sessions. 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 "$USER$DISPLAY". |