After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 101683 - gnome-control-center takes over desktop on remote machine
gnome-control-center takes over desktop on remote machine
Status: RESOLVED OBSOLETE
Product: gnome-control-center
Classification: Core
Component: general
2.6.x
Other other
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
AES[TEST2.2]
: 149786 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-12-20 14:23 UTC by Andrew Sobala
Modified: 2011-07-11 13:08 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10



Description Andrew Sobala 2002-12-20 14:23:09 UTC
Description of problem:
If you are running xhosted and you run gnome-control-center it takes the
nautilus window forks a process which takes over the desktop.

gnome-control-center should start up nautilus with the --no-desktop option.

How reproducible:
Always

Steps to Reproduce:
1. ssh -X someother-rh8.0-machine
2. gnome-control-center

	

Actual Results:  Your desktop is taken over by the nautilus from the remote
machine.

Expected Results:  Just the nautilus window for the preference opens up.
Comment 1 Andrew Sobala 2002-12-20 14:23:46 UTC
Big problem for remote machines (and someone mentioned this to me _in
person_ a while ago), so ->high.

This came from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=79319
Comment 2 Luis Villa 2004-06-07 03:26:48 UTC
Why is control center running a nautilus at all? [And I assume this isn't fixed
in 2.6, right?]
Comment 3 Jody Goldberg 2004-06-07 14:34:52 UTC
luis : running the shell or any of the capplets checks that the settings daemon
is running and starts it if necessary given that none of the capplets are of
much use without the daemon.  That's all handled nicely by bonobo.  The settings
daemon is responsible for setting up the background which is handled by nautilus.

There are two questions here
1) Why doesn't the remote shell notice the local settings daemon ?
2) Why is the user running a remote control center and assuming it will work ? 
That is a _big_ assumption.  Things will only work if the gconf on the remote
machine is connected to the local daemon.  While not impossible, it's also not
ensured to work unless it was setup specificly.  gconf/bonobo may not be
configured to allow remote connections for security reasons.

It would be a simple fix to not have the shell start the g-s-d, but that seems
pointless given that the only reason to run the shell is to get to a capplet
which do require it.

Comment 4 Sebastien Bacher 2004-11-28 01:41:58 UTC
*** Bug 149786 has been marked as a duplicate of this bug. ***
Comment 5 Matt Johnston 2009-06-03 03:48:33 UTC
This bug seems to still exist in 2.24.3 (Fedora 10) if you run Nautilus from a remote system. The desktop will be taken over by the remote nautilus (locally icons are disabled) and the keyboard shortcuts such as caps->control are lost.
Comment 6 Bastien Nocera 2010-12-09 18:11:50 UTC
(In reply to comment #5)
> This bug seems to still exist in 2.24.3 (Fedora 10) if you run Nautilus from a
> remote system. The desktop will be taken over by the remote nautilus (locally
> icons are disabled) and the keyboard shortcuts such as caps->control are lost.

That's not related. The original bug is about nautilus starting up when you launch a control-center capplet.
Comment 7 Bastien Nocera 2011-07-11 13:08:57 UTC
It won't run nautilus anymore in GNOME 3, and I don't think we behave much better these days (D-Bus activation rather than Bonobo activation).

Feel free to reopen if it actually causes problems in 2011.