I can confirm this, it's not per se a Plasma5 issue but it shows that we need to port the drakxtools systray applets to libappindicator or something similar that modern desktops understand.

Blocks: (none) => 17523
Source RPM: Mageia-6-dev1-x86_64-DVD.iso DATE.txt: Tue Jan 19 22:17:34 CET 2016 => drakxtools

(In reply to Rémi Verschelde from comment #1)
> I can confirm this, it's not per se a Plasma5 issue but it shows that we
> need to port the drakxtools systray applets to libappindicator or something
> similar that modern desktops understand.

If it hadn't been for your comment, I would have assigned to neoclust ;-)

Assignee: bugsquad => thierry.vignaud
CC: (none) => marja11

Still valid in today's Plasma5, btw.

as long as https://bugs.kde.org/show_bug.cgi?id=358328 is not fixed yes ;)

*** Bug 17777 has been marked as a duplicate of this bug. ***

CC: (none) => shlomif

valid for 

Mageia-6-dev1-LiveDVD-PLASMA5-i586-DVD.iso
DATE.txt: Sun Feb 28 07:30:00 CET 2016

valid for 

Mageia-6-dev1-i586-DVD.iso
DATE.txt: Thu Mar 10 21:45:52 CET 2016

as long as this is not fixed upstream this will always be valid ;)

(In reply to Nicolas Lécureuil from comment #8)
> as long as this is not fixed upstream this will always be valid ;)

thats disappointing ;), 
that said, it is not apparent in all DE.
its "ok" for a dev1 snapshot.

Hopefully upstream will fix it before RC(or its new name).

best list in "release notes" or "errata" for now?

(In reply to ben mcmonagle from comment #10)
> best list in "release notes" or "errata" for now?

we don't have Mga6 errata yet, we'll probably start writing them when releasing the first stabilization snapshot.

*** Bug 18174 has been marked as a duplicate of this bug. ***

CC: (none) => wilcal.int

Well, I see https://metacpan.org/pod/Gtk2::AppIndicator but i don't see an equivalent for perl-Gtk3 anywhere on metacpan.org. Can we port Gtk2::AppIndicator to something called Gtk3::AppIndicator?

libappindicator is not the right way to go for gtk+ apps.
GNotification is.

Don't know whether that would be useful for us, but I saw a blog post of someone using 
> the GNotification API with Perl application with the help of our best foreign
> library interaction perl module - FFI::Platypus
http://npointsolutions.blogspot.nl/2015/03/notify-to-your-user-in-linux.html
https://metacpan.org/pod/FFI::Platypus

(We don't seem to have perl-FFI-Platypus yet, though)

*** Bug 18354 has been marked as a duplicate of this bug. ***

CC: (none) => lebarhon

Not sure why we hadn't made this one a release blocker yet; having fully borken Mageia applets in one of our flagship DEs would not be the best for Mageia 6.

Priority: Normal => release_blocker
Severity: normal => major

*** Bug 18731 has been marked as a duplicate of this bug. ***

CC: (none) => saptech

*** Bug 18787 has been marked as a duplicate of this bug. ***

CC: (none) => herman.viaene

*** Bug 19006 has been marked as a duplicate of this bug. ***

CC: (none) => bacauanu_mihail

(btw, I tested quickly, but the networkmanager applet show as default on plasma was working fine here..)

I have the same issue with Cauldron updated this morning. New updates tiggered Mgaapplet and right- or left-clicking the applet does not lead to any reaction. The Netapplet has the same issue here as well.

CC: (none) => wim

I have the same issue with Mageia-6-sta1-x86_64-DVD.iso, there is no interaction with mouse to open the context menu from applets network & update.

CC: (none) => gualadrake

*** Bug 17875 has been marked as a duplicate of this bug. ***

CC: (none) => zen25000

*** Bug 19083 has been marked as a duplicate of this bug. ***

CC: (none) => roger.mis972

*** Bug 19084 has been marked as a duplicate of this bug. ***

To above I can only add that those icons are blurry.
(looks like some low resolution icon blown up in size, instead of using larger resolution original)

CC: (none) => fri

More ideal is to port it to system native icon support like kstatusnotifier it works in both lxqt and plasma 5 and gtk own native system.

CC: (none) => ozkyster

Is someone from the Mageia Tools group currently working on this blocker issue?

Status comment: (none) => Waiting for developer feedback
CC: (none) => thierry.vignaud
Assignee: thierry.vignaud => mageiatools

For now my GNotifications kept being silently hidden w/o any error

can you commit in a branch ? so we can test and other can help on this hard task ?

Actually it works if we use the ID of a Gnome app as application ID.

So when calling Gtk3::Application->new,
we've four choice:
1) usurping a real Gnome application ID:
=> This works but this is wrong!

2) providing an application ID
=> We got no notifications despite having no errors!

3) passing undef as application ID
=> we got the following error:
GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL'
failed at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm
line 67.

4) passing "" as application ID
=> we got:
(process:16552): Gtk-CRITICAL **: gtk_application_new: assertion
'application_id == NULL || g_application_id_is_valid (application_id)'
failed

However the doc does say a NULL value is OK:
https://developer.gnome.org/gtk3/stable/GtkApplication.html#gtk-application-new

And the annotation looks OK to me:
$ grep -A4 'parameter name="application_id"'
/usr/share/gir-1.0/Gio-2.0.gir |grep -B4 "the identifier for @applicatio"
          <parameter name="application_id"
                     transfer-ownership="none"
                     nullable="1"
                     allow-none="1">
            <doc xml:space="preserve">the identifier for @application</doc>

======================================================
Using:
$ rpm -qf /usr/share/gir-1.0/{Gtk-3.0.gir,Gio-2.0.gir,GLib-2.0.gir} /lib64/libglib-2.0.so --qf '%{sourcerpm}\n'|sort -u
glib2.0-2.49.7-1.mga6.src.rpm
gobject-introspection-1.49.1-1.mga6.src.rpm
gtk+3.0-3.22.0-1.mga6.src.rpm

BTW, Olav push the new gobject-introspection which is in SVN

We can go for #2 with an application entry in /usr/share/applications, to be shared with all apps.
The thing is it cannot be hidden, else notification won't work.

We could maybe stuff it into /usr/share/applications/localedrake-user.desktop

(In reply to Thierry Vignaud from comment #33)
> We can go for #2 with an application entry in /usr/share/applications, to be
> shared with all apps.
> The thing is it cannot be hidden, else notification won't work.
> 
> We could maybe stuff it into /usr/share/applications/localedrake-user.desktop

That sounds like a good workaround for the time being. Do you want to proceed with this solution, or try to get some feedback from GTK+3 devs about the "right" way to solve this?

Status comment: Waiting for developer feedback => Progress done on GNotification integration, but it requires an application ID to be defined somewhere

*** Bug 19630 has been marked as a duplicate of this bug. ***

CC: (none) => hamnisdude

If this cannot be fixed, we can use plasma-pk-updates for Plasma Desktop and the integrated updates management support of GNOME Software for GNOME for updates management. Both of those work just fine in their respective environments.

As for net-applet, I have no answers that don't involve NetworkManager...

CC: (none) => ngompa13

Still valid in the pretest sta2 isos. It explains why it was suddenly necessary to use MCC to establish my wifi connection, rather than just clicking on the net applet as I could with the 5.1 isos.

I realize this will be valid until fixed upstream, but I see there have been several duplicate bug reports, too. Adding the "6sta2" keyword, hopng this will make this bug easier to find and help reduce the duplicates.

Keywords: (none) => 6sta2
CC: (none) => andrewsfarm

(In reply to Thomas Andrews from comment #37)
> Adding the "6sta2" keyword, hopng this
> will make this bug easier to find and help reduce the duplicates.

Well, of all bug reports, those listed at http://madb.mageia.org/tools/blockers should be known of everyone doing QA tests, and this bug report is listed there.

Brand new M6 x86_64 Plasma from a blank drive install on real hardware this bug still persists.

(In reply to William Kenney from comment #39)

> Brand new M6 x86_64 Plasma from a blank drive install on real hardware this
> bug still persists.

Also installed from an up-to-date repo using boot.iso

*** Bug 20015 has been marked as a duplicate of this bug. ***

CC: (none) => unruh

The net+applet was working for a while on my system after I installed sta1 and updated it on Dec 17. I believe the update I did on Dec 21 did something to trigger this bug. So something is inconsistant.
(I have just put a new icon which runs draknetcenter onto the desktop so I can open the Network Center without going through MCC-- so that is one workaround, especially since MCC demands root priviledge One might just do that as a workaround).

This is not a drakxtools issue, this is a Plasma regression that breaks all gtk3 applications (whereas it works for gtk2 applications).
Those apps works with all other desktops...
So that's a Plasma issue...

Source RPM: drakxtools => plasma-workspace, drakxtools

I'll try to reach KDE and GTK people to debug this.

In case it helps, I get the following "error" messages in /var/log/messages

Jan 16 09:36:26 planet kernel: [ 2030.178630] traps: mgaapplet[6174] trap int3 ip:7f3ae813c0c1 sp:7fff60cd8be0 error:0
Jan 16 09:36:26 planet kernel: [ 2030.178635]  in libglib-2.0.so.0.5000.2[7f3ae80ed000+111000]
Jan 16 09:36:26 planet kernel: [ 2030.178657] audit: type=1701 audit(1484555786.474:122): auid=1000 uid=1000 gid=1000 ses=3 pid=6174 comm="mgaapplet" exe="/usr/bin/perl5.22.2" sig=5
Jan 16 09:36:26 planet kernel: [ 2030.180360] traps: net_applet[6175] trap int3 ip:7f633f7170c1 sp:7ffd9347e730 error:0
Jan 16 09:36:26 planet kernel: [ 2030.180368]  in libglib-2.0.so.0.5000.2[7f633f6c8000+111000]
Jan 16 09:36:26 planet kernel: [ 2030.180390] audit: type=1701 audit(1484555786.476:123): auid=1000 uid=1000 gid=1000 ses=3 pid=6175 comm="net_applet" exe="/usr/bin/perl5.22.2" sig=5
....

Jan 16 09:36:26 planet ksmserver[4901]: ksmserver: autostart service "/usr/bin/mgaapplet" finished with exit code  5
Jan 16 09:36:26 planet ksmserver[4901]: ksmserver: autostart service "/usr/bin/net_applet" finished with exit code  5

These are the only such messages from any of the applets, and are these are the applets that are having the problem with their clicks not registering. 

No idea what the significance is.

Let's summarize the situation. Correct me if one of my statements is wrong.

Plasma supports only the new StatusNotifierItem specification, but our tools and various other GTK+2 or GTK+3 applications still use the old XEmbed.

Fortunately, there is a compatibility layer for applications that still use the legacy system tray protocol (XEmbed). It's xembed-sni-proxy [1] and we do ship it. It does work for GTK+2 applications such as hexchat, but for some reason it does not work for GTK+3 applications nor Java applications, and KDE's author of xembed-sni-proxy visibly didn't try to debug this situation although several distros have been hit (I'm grateful that he did develop the compatibility layer in the first place, though). Some GTK+3 applications do work well though because they have been ported to use canonical's libappindicator.

[1] http://blog.davidedmundson.co.uk/blog/xembed_back

The solutions we have are:

1) Find out why the compatibility layer doesn't work with GTK+3. Either a bug in xembed-sni-proxy, in GTK+3 or in-between (our packaging). This is my preferred solution because it allows to fix not only our applications but also several others. Then properly port our applications to SNI for Mageia 7.

2) Port our applications so that they support SNI.

2a) The usual way seems to be libappindicator but I heard it's not something official from GTK. To be confirmed though since it's the solution that several projects adopted if I understood correctly (redshift-gtk, dropbox...).

2b) Port our applications to GNotification. Thierry did work on this and IIRC it was almost working but not entirely. Thierry, can you elaborate on that?

2c) Any other way to properly support SNI that would have GTK people's favor.

Summary: Un-clickable mgaapplet + net_applet need to be ported to GNotification => Un-clickable mgaapplet + net_applet + various other GTK apps' systray icons in Plasma

You may find something of use in this bug of mine for onboard that was successfully fixed for plasma5 - maybe worth reading the whole thing, however comment #5 para 3 is interesting.
https://bugs.launchpad.net/onboard/+bug/1553269

Created attachment 8864 [details]
IRC logs, chat with GTK+ developers

I got an interesting chat with helpful GTK+ developers on their IRC channel. Logs attached.

It *is* a bug in xembed-sni-proxy in that it sends forged events that GTK+3 don't listen to by default. 

A possible fix would be to have xembed-sni-proxy send both old-style events and newer-style events and let the event mask pick the appropriate one. This way it should work both in GTK2 and GTK3.

An ugly workaround is to start the applications that have a systray icon with GDK_CORE_DEVICE_EVENTS=1 and then it works because it forces the GTK3 application to go back 10 or 15 years back into time and listen to raw X events (if I understood correctly).

19/1/17 classical 64-bit MAgeia-6-sta2 still shows a Netapplet in systray that does not respond to selection. Have to us MCC/Network to start it.
  Also, once WiFi is connected, the netapplet icon disappears from systray!

CC: (none) => maurice

The second problem has been there since at least MGA4-- the icon for the netapplet can become invisible. It is still there-- placeing the mouse cursor on the blank space gives the "net_applet" sign above the blank space. And in MGA5, clicking on the blank space would bring up network-center. Also, this behaviour is not consistant. Sometimes the icon would be invisible, and sometimes visible. 
This is however a distinct bug (I think) from the non-response of the icon to clicks.

This bug has just celbrated its first bithday. Is it really so obscure a bug, especially one considered a blocker? Sincee many other icons on the taskbar do respond to clicks, is it not possible to kludge their response to netapplet?

(In reply to w unruh from comment #51)
> This bug has just celbrated its first bithday. Is it really so obscure a
> bug, especially one considered a blocker? Sincee many other icons on the
> taskbar do respond to clicks, is it not possible to kludge their response to
> netapplet?

If you read comment #46 and comment #48 you can see that we've made progress in identifying the underlying causes. Now either KDE folks will fix it and we'll be happy, or we'll try to patch xembed-sni-proxy ourselves, or we'll have to port Mageia applets to comply with SNI (but that would not fix other applets).

Would statusnotifier help us here?

https://github.com/jjk-jacky/statusnotifier
https://jjacky.com/statusnotifier/

And an example of an application (kalu) using it:

https://github.com/jjk-jacky/kalu/commit/24e45233c57ccbf9c5cf70cc2408ab745ccdc675

Just read that PCLinuxOS has fixed the issue with net_applet. I haven't tested it thought since it didn't boot in Virtualbox.

http://www.pclinuxos.com/distribution-release-kde-plasma-5-2017-03/#respond

Just in case it helps.. :)

CC: (none) => mageia

(In reply to Muhammad Tailounie from comment #55)
> Just read that PCLinuxOS has fixed the issue with net_applet. I haven't
> tested it thought since it didn't boot in Virtualbox.
> 
> http://www.pclinuxos.com/distribution-release-kde-plasma-5-2017-03/#respond
> 
> Just in case it helps.. :)

Tested it on real HW and it works on Plasma 5. Could this be of any help to Mageia?

(In reply to Muhammad Tailounie from comment #56)
> (In reply to Muhammad Tailounie from comment #55)
> > Just read that PCLinuxOS has fixed the issue with net_applet. I haven't
> > tested it thought since it didn't boot in Virtualbox.
> > 
> > http://www.pclinuxos.com/distribution-release-kde-plasma-5-2017-03/#respond
> > 
> > Just in case it helps.. :)
> 
> Tested it on real HW and it works on Plasma 5. Could this be of any help to
> Mageia?

Yes, if their net_applet is the same as our net_applet. We'll have a look, thanks!

Hi,

they have fixed nothing but forced an workaround

export GDK_CORE_DEVICE_EVENTS=1



this is not what i call a fix :)

As if pclinuxos ever did some real work or contribute back...

I spent some time this week testing libappindicator and statusnotifier. I have a preference for the latter (statusnotifier) for several reasons:

- Status icons created with statusnotifier accept left clicks to trigger the actions you want. libappindicator ignores left clicks and you cannot do anything against it, AFAICS.

- libappindicator last release is 5 years old (July 2012) and seems to not get traction anymore while the author of statusnotifier is still active and spent some time to help me to make it work nicely with Perl. Such a help was very appreciated. He even already fixed a small bug I reported yesterday. And he expects to do another release soon.

- I tried to compile libappindicator myself (I know it's already packaged, but this was for comparison purposes). The *huge* list of dependencies was a nightmare, and I never managed to compile it without errors. On the other hand, statusnotifier has so special dependencies besides the obvious ones (gio, glib, etc...) and compiled correctly in the first shoot.

- They are both easy to use from Perl, so this criteria doesn't matter. :)


I expect to have some free time this afternoon to work on this, so if everything goes well, I should have something to show later this evening.

Status: NEW => ASSIGNED
Assignee: mageiatools => LpSolit

commit 7e230ad67b6cbe99939026ea48ee6aa2728eb316
Author: Frédéric Buclin <LpSolit@...>
Date:   Fri Mar 3 21:05:55 2017 +0100

    Fix the mgaaplet status icon (mga#17592)
---
 Commit Link:
   http://gitweb.mageia.org/software/mgaonline/commit/?id=7e230ad67b6cbe99939026ea48ee6aa2728eb316

commit d15d7d0211b9e4e52a53aa4a349641c02b6a8474
Author: Frédéric Buclin <LpSolit@...>
Date:   Sat Mar 4 02:04:38 2017 +0100

    Fix the net_applet status icon (mga#17592)
    
    This also restores the tooltip with IP information.
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx-net/commit/?id=d15d7d0211b9e4e52a53aa4a349641c02b6a8474

I'm happy to say that thanks to Frédéric Buclin (LpSolit)'s work, we now have working applets in Plasma in mgaonline-3.18-1.mga6 and drakx-net-2.28-1.mga6! ð

On plasma, mgaapplet and net_applet use the statusnotifier library to generate a SNI compliant systray applet. On other DEs, as most of them don't support SNI out of the box, we keep using the previous code using GtkStatusIcon. Some DEs can get SNI support if they are configured properly (e.g. LXQt with a config, or Xfce with a plugin), so that might be something we'll want to look into if there were issues with the legacy applet on those DEs.

@ Bugsquad: The above should fix the issues with mgaapplet and net_applet, but not thirdparty GTK+3 apps that are no longer working with Plasma's xembedsniproxy. Still, for clarity, I would propose that we close this bug as FIXED, and clone it to a new bug specific to xembedsniproxy / plasma-workspace. WDYT?

(In reply to Rémi Verschelde from comment #63)
> @ Bugsquad: The above should fix the issues with mgaapplet and net_applet,
> but not thirdparty GTK+3 apps that are no longer working with Plasma's
> xembedsniproxy. Still, for clarity, I would propose that we close this bug
> as FIXED, and clone it to a new bug specific to xembedsniproxy /
> plasma-workspace. WDYT?

That cloned report would not be a release blocker for Mageia 6, though I would still keep it high priority for our kde@ group. If we can find a fix a contributing upstream, it would be a great downstream contribution from Mageia.

Please don't clone this bug but file a new one. Cloning a bug also clones the whole CC list, which generates a lot of spam, especially for those who are not interested in the subsequent bugs.

Target Milestone: --- => Mageia 6

Marking this bug as FIXED as both mgaapplet and net_applet have been fixed. Please someone file a separate bug about xembed-sni-proxy being broken with Gtk3.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED
Summary: Un-clickable mgaapplet + net_applet + various other GTK apps' systray icons in Plasma => Un-clickable mgaapplet + net_applet systray icons in Plasma