FFE: No easy way to turn the network menu on/off

This is not a bug in NetworkManager or nm-applet. nm-applet gets started by gnome-session, so it really should be able to allow a user to define what goes into the session. This used to be possible in gnome-session-properties; and now appears to be done via removing the file /etc/xdg/autostart/nm-applet.desktop.

However, nm-applet does still fulfill a purpose: it allows you to quickly know whether your cable is connected. It also allows you to change wifi networks should it be required. It's also very much out of the way like other indicators, especially if all you'd have is a wired connection. I do not think it's using enough screen real-estate in the panel as it as that it's so much of an issue.

Now, I however don't think it's fair to just close this off as Invalid or Opinion; so I'll keep this bug open as a Wishlist, Low priority item that someone might want to tackle if they want to get to know nm-applet better.

Note that anybody working on this will undoubtedly want to coordinate with the NetworkManager mailing list about this, since the feature could benefit upstream (since it's usability, and the original GtkStatusIcon or gnomeshell status icon give roughly the same user experience).

I believe gnome-session-properties -- or any successor to it -- would not be an appropriate interface for configuring whether the menu is visible, for three reasons. First, people do not think of the network menu as something that is "started" or "launched". Second, any change in whether it is visible should apply instantly, not on next login. And third, the clock menu has -- and some other status menus will have -- settings for what is inside them, the setting for whether that kind of menu is present at all should be immediately above those extra settings, and the setting for whether any status menu is present at all should be in the equivalent place regardless of whether that menu has extra settings.

For similar reasons, administrative items that were shown in gnome-session-properties are being moved to more appropriate places. <https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-startup-applications>

Each individual menu does not take much space, but that's the logic that led to the Windows notification area disaster. :-) They add up. So I'm not making an exception for the network menu here; for the equivalent in other menus see bug 829690, bug 829664, bug 811769, and bug 829648.

So, since these are functional changes I've subscribed the ubuntu-release team.

The changes required are pretty simple and I'm already done preparing patches for both nm-applet and gnome-control-center. Essentially, nm-applet needs to carry an extra gconf key "show-applet" that will be toggled based on the user's request to show or hide the applet, and g-c-c needs a small UI change consistent with the bluetooth panel to add the checkbox that will toggle this gconf setting at the bottom of the Network panel.

See attached screenshot.

On Monday, February 20, 2012 07:10:05 PM you wrote:
> So, since these are functional changes I've subscribed the ubuntu-
> release team.

Do any of these changes affect integration with the KDE NM widget?

No, it's only meant for nm-applet to be hidden when the gconf key is set to false. The only effect for KDE would be if a user was using nm-applet rather than the plasma applet.

OK. What will happen in that case (what's the default)? A lot of Kubuntu users (including me) keep nm-applet installed just in case of problem.

The default is to show the applet, they will only be able to hide it by using gconf-editor or the gnome-control-center application to change the /apps/nm-applet/show-applet key.

Sounds good. Approved.

This bug was fixed in the package network-manager-applet - 0.9.2.0+git.20120126t000800.5151959-0ubuntu3

---------------
network-manager-applet (0.9.2.0+git.20120126t000800.5151959-0ubuntu3) precise; urgency=low

  * debian/patches/lp829673_gconf_hide_applet.patch: allow toggling the applet
    visibility. (LP: #829673)
  * debian/patches/nm-applet-use-indicator.patch: completely replace the old
    wireless menu item creation code overriding NMNetworkMenuItem objects to
    rewrite it more simply with GtkImageMenuItems. This should really take care
    of the memory leaks. (LP: #930491)
 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 20 Feb 2012 13:58:49 -0500

This bug was fixed in the package gnome-control-center - 1:3.3.5-0ubuntu5

---------------
gnome-control-center (1:3.3.5-0ubuntu5) precise; urgency=low

  * debian/patches/lp829673_hide_nm-applet.patch: provide a way for users to
    hide the network applet from the Network settings panel. (LP: #829673)
 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 21 Feb 2012 10:03:59 -0500

FWIW, your nm-applet patch causes a regression in Xubuntu, since now we have nm-applet both in the systray and the indicator-plugin... If we need some action for xubuntu-default-settings (set the gconf key to false), I guess it's better to warn/notify us somehow (my changelog-analysing-heuristic-for-sneaky-changes-post-feature-freeze is not that efficient :).

To put it in a nutshell, should I set '/apps/nm-applet/show-applet' to FALSE by default in xubuntu-default-settings, or will the patch behavior/key name/key default value change in the near future?
Thanks.

I confirm the nm-applet appearing in both places (on xubuntu 12.04); unfortunately the new key also affects both, so we either have no applet or too much applet.

What are the options to fix the regression caused by this change?

Unfortunately, as Nicolas wrote, the description of the gconf key added by the patch was wrong (it says 'hide it from the notification area', while it hides it from everywhere), see <https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/938380/comments/24>.

So when a fixed nm-applet is uploaded (cf. https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/938380/comments/15), I'll need to make an upload of xubuntu-default-settings to revert this commit: http://bazaar.launchpad.net/~xubuntu-dev/xubuntu-default-settings/trunk/revision/354 (introduced in 12.0.4.7). And everything should be fine.

It's not really a big problem, anyway (but the fact that the documentation included in the patch is wrong is really annoying post feature freeze, I wouldn't have made the xubuntu-default-settings change otherwise...).

FYI, problem solved with the latest nm-applet and xubuntu-default-settings uploads. Thanks.

Yup, I also have only one nm-applet again (the indocator version), and this is good.

Although for a short time, the menu was near empty (no wireless menus except for the activation option, no VPN options). I launched a new nm-applet, resulting in two indicators, and both had a complete menu. I kill the one I manually launched, and the original one retained the complete menu. I don't yet know if it was a one-time glitch; I'll do some more tests.

Still a problem in gnome-control-center 1:3.3.91-0ubuntu2 -- the checkbox is AWOL.

those options got dropped from the control center by design decision from John, agreed by Olli

So, what's the expected behavior? Should we re-add the patch to provide the checkbox, or can we close this bug report as Invalid or Won't Fix or some other status if there shouldn't be a checkbox at all?

Unassigning since there's probably nothing else to be done there...

Unsubscribing ubuntu-release, there doesn't appear to be anything here for us any more.