Red Hat Bugzilla – Bug 449976
Can't remove NetworkManager applet per single user's panel via GUI
Last modified: 2009-02-14 16:30:26 EST
Description of problem:
NetworkManager-applet has somehow decided that it is so incredibly important
that no user would ever consider removing it from the panel. So, there is no
"Remove from panel" option like there has been on every applet I have seen since
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Login with GNOME.
2. Right click on NetworkManager applet
No "Remove from panel" option.
There should be a "Remove from panel" option.
I am on a workstation connected directly to the Internet.
You may 'rpm -e NetworkManager-gnome' if you like. We just happen to install
the package by default, and it lives in the notification area just like Gnome
Power Manager does. The way to remove it is to remove the package.
But in Power Management Preferences, there is a choice "Never display an
icon"/"Always display an icon", for desktop users who don't need to see it.
It's not necessary to remove a package there. Not only that, but that allows it
to be an individual user preference, unlike the choice of whether a package is
No, the way to remove it is to right click on the applet and select "Remove From
Saying "remove the RPM" is silly and out of touch. Why should this applet be
different from any other?
Wait a second, if this is a notification area applet -- which it is -- then you
can get rid of it on a per-user basis with the session config tool, just as with
every other notification area applet since GNOME <some_long_ago_version>. Go to
System -> Preferences -> Personal -> Sessions, and clear the checkbox for
NetworkManager. On your next login you will no longer see the applet. This is
the same procedure used for many other notification area applets (which are
different from regular panel applets).
I tried enabling the NetworkManager service, disabling the network service, and
checking the "Controlled by NetworkManager" box for eth0 in
system-config-network, unchecking the "Network Manager" box in
System/Preferences/Personal/Sessions as you suggested, and rebooting. It
doesn't work, the applet is still there with no obvious way of getting rid of it
(except removing NetworkManager-gnome, which I prefer not to do).
The only way to remove the applet from the notification area is to remove
Maybe the Summary of this bug should be changed to "Cannot get rid of
NetworkManager applet on per-user basis".
> The only way to remove the applet from the notification area is to
> remove NetworkManager-gnome.
That is the bug: The way to remove applets is via the GUI interface, only for
the user that wants it removed from his/her panel, not by having to rpm -e the
package and remove it for all users!
Please consider changing the bug summary to something along the lines of comment
#7 to indicate that the problem is specifically about removing the applet on a
per-user basis. Also see bug #456046 which I suspect is related in that it also
concerns problems with the NetworkManager applet and multiple users.
I changed the summary. I don't care so much about per user, though that's an
implication. In my mind, the problem is that the applet can't be removed in the
same manner any other applet can be removed. For this applet's behavior that
implies it affects other users, but I want to be sure that this doesn't get
"fixed" via some hack.
Point is, this applet ain't special. It should be like any other applet in how
it is added or removed.
I think "per user" and "same as other applets" are equivalent, since the way
other applets are removed is via ordinary user permissions, which means it can
only be allowed to affect the given ordinary user who does it. (Removing the
NetworkManager-gnome package requires root and affects all users.) But
describing it as "per user" more specifically describes the currently missing
functionality (which is worse than just funky behavior).
Ok, hopefully now I've captured both our thoughts. :)
Please update the version to "10", since nothing's changed.
*** This bug has been marked as a duplicate of bug 429431 ***