Bug 15940 - Superfluous Network Manager Systray icon with Cinnamon, LXDE, Mate, XFCE desktops
Summary: Superfluous Network Manager Systray icon with Cinnamon, LXDE, Mate, XFCE desk...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
: Normal normal
Target Milestone: Mageia 6
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-15 12:36 CEST by Lewis Smith
Modified: 2017-05-08 21:36 CEST (History)
8 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description Lewis Smith 2015-05-15 12:36:04 CEST
Description of problem:
This is an old problem re-introduced with Mageia 5 Classic DVD.
Cinammon, LXDE, Mate, XFCE desktop Systrays have *2* 'network' icons: the correct operational 'Globe' one with its 8-item menu; plus a redundant and inoperative '2-terminal' icon apparently for Network Manager, which says the network is unavailable and NM is not running.

Version-Release number of selected component (if applicable):
Mageia 5 pre-release RC and Final at least, without doubt all the way.

How reproducible:
Always visible from an installation with all 6 desktops.

Steps to Reproduce:
Not applicable.

Reproducible: 

Steps to Reproduce:
Comment 1 Jani Välimaa 2015-05-15 18:12:25 CEST
At least Cinnamon pulls networkmanager-applet.

IMHO you'll have to live with this if you do such special install with all 6 DEs and one of them requires nm-applet and the other DEs doesn't need it and pulls drakx-net-applet. Both pkgs installs xdg autostart .desktop file so both are started until you disable the one you don't want to use.

It's another story if this happens when only one DE is installed.
Comment 2 David Walser 2015-05-15 18:39:26 CEST
IMO no desktops for Mageia should be requiring NetworkManager stuff.
Comment 3 Sander Lepik 2015-05-16 13:13:35 CEST
NM is deeply built into Gnome AFAIK, you can't install Gnome w/o it. There might be other DEs as well that now require it and we can't do much about it.
Comment 4 Samuel Verschelde 2016-10-10 22:40:54 CEST
Is this problem still present in latest cauldron?
Comment 5 Lewis Smith 2016-10-11 20:14:56 CEST
(In reply to Samuel Verschelde from comment #4)
> Is this problem still present in latest cauldron?
That I cannot tell. I will have to await the re-introduction of working Mageia 6 Classical ISOs. When that happens, I will come back to this.
Comment 6 Philippe Makowski 2016-12-10 15:05:10 CET
Cinnamon is now working very well with NM, that's the net_applet that should be disable, not the NM one.
NM is the good choice for Gnome and for Cinnamon.
and when I read https://bugs.mageia.org/show_bug.cgi?id=7317#c33 I agree with Colin, better to rely on NM.
Comment 7 Marja van Waes 2016-12-17 18:00:02 CET
What happened to the Live isos, didn't they switch to using NM, too, or was that reverted? And wasn't there a plan, if that worked well for the Lives, to switch the classical installs to NM, too?

CC'ing the isobuilders.
Comment 8 Martin Whitaker 2016-12-17 18:35:15 CET
The GNOME Live DVDs were switched to NM (before I started work on them), and in general it seems to work very well. The only annoyance is that after installing from the Live DVD, on the first boot of the installed system, drakx-net(1) is called to configure the network, and it conflicts with NM and always fails. Once you get to the desktop, NM can be used and works fine. So if we are going to stick with this change (and I think we should, as NM is prominently integrated into the GNOME desktop), drakx-net either needs to be fixed to work with NM or needs to be disabled on the GNOME Live DVDs.

The Plasma Live DVDs are still using net_applet. If there is a desire to change this, speak up soon - we shouldn't make significant changes like this after sta2 is released.

(1) Probably not the right name, but you know what I mean.
Comment 9 Neal Gompa 2016-12-17 18:40:21 CET
(In reply to Martin Whitaker from comment #8)
> 
> The Plasma Live DVDs are still using net_applet. If there is a desire to
> change this, speak up soon - we shouldn't make significant changes like this
> after sta2 is released.
> 

I would like to see us migrate from drakxnet to using NetworkManager and plasma-nm on Plasma 5. I've been using it as a daily driver for months and it's been absolutely rock-solid. Wherever we can, we should switch the defaults to NetworkManager and disable drakxnet.
Comment 10 Thomas Backlund 2016-12-17 19:09:53 CET
(In reply to Martin Whitaker from comment #8)
> The GNOME Live DVDs were switched to NM (before I started work on them), and
> in general it seems to work very well. The only annoyance is that after
> installing from the Live DVD, on the first boot of the installed system,
> drakx-net(1) is called to configure the network, and it conflicts with NM
> and always fails. Once you get to the desktop, NM can be used and works
> fine. So if we are going to stick with this change (and I think we should,
> as NM is prominently integrated into the GNOME desktop), drakx-net either
> needs to be fixed to work with NM or needs to be disabled on the GNOME Live
> DVDs.
> 

set NETWORK=no in /etc/draklive-install.d/sysconfig

and for net_applet:

set AUTOSTART=FALSE into ~/.net-applet


> The Plasma Live DVDs are still using net_applet. If there is a desire to
> change this, speak up soon - we shouldn't make significant changes like this
> after sta2 is released.
> 
> (1) Probably not the right name, but you know what I mean.


ensure plasma-applet-nm is on the plasma isos and disable network and enable networkmanager like done for gnome
Comment 11 Martin Whitaker 2016-12-18 15:30:15 CET
I've tested these changes on the Live DVDs locally. For GNOME, everything works smoothly with the minimum of fuss. For Plasma, when you try to connect to a wireless network, there's a more tortuous process involving KWallet. Following the default suggestion of using GPG, you get told there are no suitable keys on your system. I don't think this is suitable for the novice user.
Comment 12 Neal Gompa 2016-12-18 15:38:00 CET
(In reply to Martin Whitaker from comment #11)
> I've tested these changes on the Live DVDs locally. For GNOME, everything
> works smoothly with the minimum of fuss. For Plasma, when you try to connect
> to a wireless network, there's a more tortuous process involving KWallet.
> Following the default suggestion of using GPG, you get told there are no
> suitable keys on your system. I don't think this is suitable for the novice
> user.

KWallet should only be triggered if plasma-nm is saving Wi-Fi credentials to the local user. When set to save for all users (that is, the connection is setup up so any and all users can use it), it should not trigger.

I believe GNOME's default behavior is that, which keeps it from showing the GNOME Keyring stuff, but Plasma is probably defaulting to local store rather than global store.
Comment 13 Martin Whitaker 2016-12-18 22:38:55 CET
(In reply to Neal Gompa from comment #12)
> KWallet should only be triggered if plasma-nm is saving Wi-Fi credentials to
> the local user. When set to save for all users (that is, the connection is
> setup up so any and all users can use it), it should not trigger.
> 
> I believe GNOME's default behavior is that, which keeps it from showing the
> GNOME Keyring stuff, but Plasma is probably defaulting to local store rather
> than global store.

Well, unless someone changes the defaults, I'm going to leave well alone and just apply the final fixes for GNOME. I don't think QA would thank me for doing otherwise!
Comment 14 Rémi Verschelde 2017-01-03 16:00:31 CET
(In reply to Martin Whitaker from comment #13)
> (In reply to Neal Gompa from comment #12)
> > KWallet should only be triggered if plasma-nm is saving Wi-Fi credentials to
> > the local user. When set to save for all users (that is, the connection is
> > setup up so any and all users can use it), it should not trigger.
> > 
> > I believe GNOME's default behavior is that, which keeps it from showing the
> > GNOME Keyring stuff, but Plasma is probably defaulting to local store rather
> > than global store.
> 
> Well, unless someone changes the defaults, I'm going to leave well alone and
> just apply the final fixes for GNOME. I don't think QA would thank me for
> doing otherwise!

Agreed. I've been using plasma-nm-applet on Plasma 5 for one year, and never manage to find how to get it *not* to ask me for my user password at each boot, so I'm still stuck doing it every single time I boot, it's annoying. The options it seems to give to change the polkit stuff are not working. At any rate, it's can't be considered as working "out of the box".
Comment 15 Lewis Smith 2017-03-06 10:37:45 CET
(In reply to Samuel Verschelde from comment #4)
> Is this problem still present in latest cauldron?

STA2: still present for LXDE, Mate, XFCE; but has disappeared for Cinnamon. Adapting the title accordingly.
Comment 16 Lewis Smith 2017-03-08 15:07:36 CET
Correction to Comment 15

M6_STA2 as released & updated to now.
For terminology, I now see that the 'globe' (M5) = vague blue icon (M6) = net_applet, always present, always functional.
The other 'double-terminal' icon is apparently for Network Manager, and is inoperative.

It was *not* true that this problem had disappeared from Cinnamon for Mageia 6; it just looked different. In systray there was a second network icon which said something like 'network disabled', and which allowed itself to be removed. The offending duplicate. However, it then re-appeared in systray in its old double-terminal form, inoperative, which you cannot remove.

Confirmed explicitly that this problem remains for Cinnamon, LXDE, Mate, XFCE. It is simply confusing. Bug title updated.
Comment 17 Lewis Smith 2017-03-13 19:58:21 CET
Trying the new STA2 XFCE Live system, installed, I notice that the superfluous systray double-terminal icon is *not* present; just the functional one.
In case this helps.
Comment 18 Lewis Smith 2017-05-08 21:36:52 CEST
RC Classic ISO dated today.
Still the redundant & useless taskbar double-terminal icon for XFCE. To confirm for the other minority desktops. After which we can close this bug, I think.

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