Bug 429431 - nm-applet: not possible to quit/disable (?)
Summary: nm-applet: not possible to quit/disable (?)
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 12
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 449976 (view as bug list)
Depends On:
Blocks: F9Target
TreeView+ depends on / blocked
 
Reported: 2008-01-19 22:08 UTC by Rex Dieter
Modified: 2010-02-14 14:47 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-02-09 03:08:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Rex Dieter 2008-01-19 22:08:59 UTC
Raising mostly in the context of KDE Spin (and other non-gnome desktops).  

The issue I'd like to raise here is that if someone, like a KDE user, would
prefer to use knetworkmanager.  With NetworkManger-gnome, if installed and
afaict, there seems to be no way to disable it or quit after launch.    As is,
that user would get both applets.

I'm not sure how best to handle a situation like this.  Any suggestions?

Comment 1 Kevin Kofler 2008-01-19 22:12:34 UTC
Also note that this is exacerbated by the fact that we had to ship 
NetworkManager-gnome by default in Fedora 8 because KNetworkManager wasn't 
ready. Now it looks like we've got a KNetworkManager ready for Rawhide (and 
probably also want to push it to the Fedora 8 updates at some point), so we 
need an upgrade path (and Obsoletes is not an option for obvious reasons).

Comment 2 Kevin Kofler 2008-01-19 22:14:12 UTC
(knetworkmanager in F8 and current Rawhide is a dummy package which dragged in 
NetworkManager-gnome because we didn't have any other working options.)

Comment 3 Dan Williams 2008-01-20 02:21:13 UTC
Hmm; could the new knm package include a small shim that copies settings from
GConf into the config store that knm used?  Then you could patch that into
knetworkmanager's startup code and copy them over once, set a private config key
to say "already converted" and don't copy again if that key is found.

Or, since it's one-time-pain, just ignore the existing GNOME settings and have
people re-enter the stuff.  Sort of sucks, but you'd only have to do it once.

Comment 4 Kevin Kofler 2008-01-20 12:19:33 UTC
Thanks for the hints, but copying the configuration isn't our primary concern, 
getting the NM-gnome nm-applet not to start is, because 2 NM applets at the 
same time would trip on each other.

Comment 5 Bug Zapper 2008-05-14 04:49:06 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Craig Kelley 2008-05-30 17:10:36 UTC
The NM applet is practically useless on a workstation with a dedicated
connection.  I would like to be able to at least hide it to prevent it from
using up space in the panel.

Comment 7 Rex Dieter 2008-06-17 20:36:25 UTC
(As suggsted by ivazquaz on #fedora irc)

when/if a "new" default kde applet comes, it could include a (kde-specific):
/usr/share/autostart/nm-applet.desktop
that includes key:
Hidden=true

according to my reading of the xdg-autostart spec, would be at least one
system-wide way to disable nm-applet in kde.


Comment 8 Dan Williams 2009-02-14 21:30:26 UTC
*** Bug 449976 has been marked as a duplicate of this bug. ***

Comment 9 Rex Dieter 2009-02-14 23:01:10 UTC
Bummer that my trick from comment #7 doesn't seem to work in KDE, but from what we can tell, it's *supposed* to work, so may be indicative of a bug.  We're looking into it.

Comment 10 Bug Zapper 2009-06-09 23:24:11 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Bug Zapper 2009-11-16 08:00:33 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 12 Dan Williams 2010-02-09 01:24:29 UTC
I think the major problem here is how you'd get the applet back in the panel in an easy and discoverable way after hiding it...

Comment 13 Rex Dieter 2010-02-09 03:08:17 UTC
Agreed, I withdraw the request.

This is probably better implemented in some sort of service/autostart manager.  I'll (hopefully) be hacking on kde's autostart manager soonish to implement something along the lines of this.

While I'm at it, I'll also see about making something like comment #7 work too (it's probably a kde bug that it doesn't currently work).

Comment 14 Raul Acevedo 2010-02-09 03:43:09 UTC
No, please don't close this bug; I filed bug 449976, which was deemed a dupe of this one, 

Why can't this applet behave like any other applet, that you get rid of with right click -> Remove from panel, and add via right click -> Add to panel?

I really don't understand why this is so difficult.  Is there something this applet does or how it works that it cannot work like every other applet?

Comment 15 Rex Dieter 2010-02-09 04:13:12 UTC
Strictly speaking your wish was a little different than mine here.

I wanted a way to simply disable nm-applet (per user or per system), and I think I've come up with some better ways to do that.

You seem to want the ability to get rid of it once launched (which I have no personal interest in).

Comment 16 Kevin Kofler 2010-02-09 13:04:33 UTC
IMHO nm_applet should just be NotShowIn=KDE; in F13 and higher, but we can discuss this in today's KDE SIG meeting.

Comment 17 Kevin Kofler 2010-02-09 13:05:32 UTC
(Please don't add a NotShowIn in F11 or F12 updates or you'll break networking for unsuspecting users.)

Comment 18 Raul Acevedo 2010-02-09 18:53:08 UTC
Rex: If your wish is considered different, then I would like my bug re-opened.  Regardless, I want to understand why this applet can't be like any other applet on the panel: you remove with a right click, add it back with a right click.

What is wrong with this?

Comment 19 Rex Dieter 2010-02-09 18:59:19 UTC
Re-open your bug then, if you want.  All I'm saying is that I'm not personally interested in that (anymore).

Comment 20 Kevin Kofler 2010-02-09 19:00:41 UTC
nm-applet is not a panel applet, it's a systray icon.

Comment 21 Milan Masek 2010-02-14 13:27:02 UTC
Hi all,
This bothering me a lot as a KDE user.
For all of you who wants to get rid of this stupid behaviour:
edit file '/etc/xdg/autostart/nm-applet.desktop' and put there a new line:
OnlyShowIn=GNOME

M.

Comment 22 Kevin Kofler 2010-02-14 14:47:09 UTC
This will be the default in F13 and up, where we default to knetworkmanager (see the closed bug 541353), but we can't really do this by default in F11 and F12 or we'll break networking for our users. If your system is a single-user system or if everyone is using KDE, you can just remove the NetworkManager-gnome package altogether.


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