Bug 164786

Summary: Some gtk apps don't show on the systemtray
Product: [Plasma] plasma4 Reporter: Nicolas L. <kde>
Component: widget-systemtrayAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: aseigo, johannes.simon, kde-2011.08, l.lunak, mail, mkem, olfway, tuju
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: testcase in C
patch that *may* fix it
patch that *may* fix it, second try

Description Nicolas L. 2008-06-23 22:04:20 UTC
Version:            (using Devel)
Installed from:    Compiled sources
OS:                Linux

Some gtk apps don't show on the systemtray, like the mandriva net_applet that only show an empty space on the systemtray when enabled.
Comment 1 Nicolas L. 2008-06-23 22:40:31 UTC
this seems only related to perl_gtk applications.
All was ok with kde 4.0.x
Comment 2 Sebastian Sauer 2008-06-24 02:01:36 UTC
Hi Nicolas,

when did you compiled KDE? If you are using a version before r822917 from Sunday 22 June then it's a duplicate of bug #164320 else it's another issue that need to be addressed. Thanks for more details there :)
Comment 3 Sebastian Sauer 2008-06-24 02:03:06 UTC
hmmm... thinking again, it doesn't really sound like being related to bug #164320 at all. What does happen if you exit the net_applet and then start it again? does it show up then?
Comment 4 Nicolas L. 2008-06-24 07:26:25 UTC
i use Beta2.

If i quit net_applet, the place on the systray is freed and if i start it again the empty space appear again
Comment 5 Sebastian Sauer 2008-06-24 08:26:17 UTC
ok, sounds like another issue then. 

Unfortunately I don't have Mandriva installed but did install something named "netapplet" which seems to be a systray-application ( aka identical to http://wiki.mandriva.com/en/Tools/NetApplet ) and it works fine here. The icon is displayed correct. So, seems I can't reproduce it :-/

Any hint how the other perl_gtk systray-applications are named so I can't give them a try too?
Comment 6 Nicolas L. 2008-06-24 10:06:00 UTC
yes net_applet this also called netapplet. unfortunatly i don't know any apps in perl_gtk outside of mandriva :/


do you need me to do some tests on my mandriva ?
Comment 7 Sebastian Sauer 2008-06-24 20:18:50 UTC
let's mark this bug as duplicate of bug #164656 since the other deals already with it plus I did assign it already to me and will look this evening what may the reason / how it could be probably fixed.


*** This bug has been marked as a duplicate of 164656 ***
Comment 8 Nicolas L. 2008-06-24 23:50:55 UTC
it do not seems to be the same as bug 164656
Comment 9 Sebastian Sauer 2008-06-25 00:04:29 UTC
well, the "there are weird empty spaces in the system tray notification area (very probably some notification icons being invisible),... " part does. But you are right, if it turns out not to be the same issue I'll reopen (or better find the reason + fix it + reopen + mark as fixed) this report.
Atm I prepare my environment to be able to reproduce this (and take a look at Cooker :-) what should provide then a way to proper test and fix it :)
Comment 10 Frederic Crozat 2008-06-25 18:37:30 UTC
Created attachment 25605 [details]
testcase in C

it is not a perl_gtk bug but a timing bug in kde4

I've attached a pretty simple testcase in C showing this.

If you comment g_usleep call, trayicon is displayed. If you enabled it, it is
hidden.
Comment 11 Rex Dieter 2008-06-25 18:43:01 UTC
Fwiw, nm-applet (aka NetworkManager-gnome) does the same thing, leaving a blank entry in systray, at least until I restart plasma.
Comment 12 Nicolas L. 2008-06-25 20:10:46 UTC
reopening
Comment 13 Sebastian Sauer 2008-06-26 23:44:23 UTC
thx. funny "workaround";
1) remove the dolphin-icon from the panel
2) kquitapp plasma
3) plasma
4) crash ( bug #164861 ) but now the net_applet+etc. are visible.

could please anybody who's still able to reproduce this provide the output of 
"xwininfo -name net_applet" (or "xwininfo -name nm_applet")? Thx in advance :)
Comment 14 Nicolas L. 2008-06-26 23:47:49 UTC
see the result here :

$ xwininfo -name net_applet

xwininfo: Window id: 0x3a00003 "net_applet"

  Absolute upper-left X:  1040
  Absolute upper-left Y:  980
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 22
  Height: 22
  Depth: 24
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsUnviewable
  Override Redirect State: no
  Corners:  +1040+980  -218+980  -218-22  +1040-22
  -geometry 22x22+0-0

Comment 15 Nicolas L. 2008-06-26 23:49:38 UTC
just tested your workaround and this works for me too :)
Comment 16 Sebastian Sauer 2008-06-26 23:58:42 UTC
Map State: IsUnviewable

so, we try to embedClient to early...
Comment 17 Nicolas L. 2008-06-27 00:01:01 UTC
just for info, after your workaround, Map State is now :

Map State: IsViewable
Comment 18 Sebastian Sauer 2008-06-27 00:07:05 UTC
at some situations (timing as sayed correct by Frederic at comment #10) the systray is created before the panel, destroyed again and the created again and before it was only leading to layout-probs but now also to crashes. See here also bug #164445.
Comment 19 Sebastian Sauer 2008-06-27 00:56:12 UTC
well, at least s/crashes/IsUnviewable/ ... 

just a sidenote I ask myself; at SystemTrayContainer::prepareFor we do XCreateWindow but never XDestroyWindow and - if I did got it right - QWidget::destroy (qwidget_x11.cpp) does only destroy if WA_WState_Created is true (or if QWidget::create() is called with WId,true,true which does not happen at the dtor)... So, should we probably manually XDestroyWindow?!
Comment 20 Sebastian Sauer 2008-06-27 01:44:31 UTC
re comment #19; ah, no. Qt does destroy it. So, it's not that easy :-/
Comment 21 Sebastian Sauer 2008-06-27 02:03:49 UTC
*** Bug 162656 has been marked as a duplicate of this bug. ***
Comment 22 Sebastian Sauer 2008-06-28 06:06:34 UTC
Created attachment 25661 [details]
patch that *may* fix it

the patch tries to address 2 cases;
1) we delay the SystemTrayWidget::init() call a bit to be sure we don't ask x
for the systray-icons at a time where we are probably not initialized yet. This
*should* work around the startup-issue.
2) after calling QX11EmbedContainer::embedClient() check if we still have a
valid clientId. This fixed a case I was able to reproduce with pidgin which if
started again while there was already an instance running does fire up a
SYSTEM_TRAY_REQUEST_DOCK message, the app quits and what stays is an invalid
trayicon that takes space but doesn't display anything.
Comment 23 Nicolas L. 2008-06-28 09:56:21 UTC
i just pushed this patch on mandriva cooker to see with users if this is Ok for them.

thanks and i come later with more infos :)
Comment 24 Nicolas L. 2008-06-28 14:16:04 UTC
for me this is still valid with this patch. I have this behaviour with apps like Gajim when it starts with KDE
Comment 25 Sebastian Sauer 2008-06-29 17:53:18 UTC
Nicolas: just to be sure; and to increase the height of the panel does still not show the icon? hmpf, then it seems to be more complicated :-/
Comment 26 Sebastian Sauer 2008-06-29 18:10:20 UTC
btw, and to remove the systray from the panel and then add it again to the panel does fix it aka let's the icon(s) appear?!
Comment 27 Nicolas L. 2008-06-29 18:17:01 UTC
after testing the patch, i completly restarted KDE
you want in + that after this i remove the systray and add it back ? with the patch or without it ?
Comment 28 Sebastian Sauer 2008-06-29 18:56:57 UTC
right, remove the systray using e.g. the "add widgets" or just right-click and remove and then add it again using those "add widgets" dialog (with the patch applied).
I ask cause last hours of running through the gtk-systray code, the qt-code, etc. I found just to many possible reasons for it and without trying to decrease possible reasons for it, it's hard to find a proper fix (to bad I can't reproduce it any longer at my cooker after I did discover and used the "workaround" from comment #13, hmpf).
Comment 29 Rex Dieter 2008-06-29 19:00:08 UTC
tried patch from comment #22, didn't help here with nm-applet (NetworkManger-gnome) (from comment #11)
Comment 30 Rex Dieter 2008-06-29 19:01:05 UTC
sorry, meant to include too that remove systray, add systray, it does (re)appear.
Comment 31 Nicolas L. 2008-06-29 19:51:08 UTC
i tested and without the patch, and if i remove the systray and add it back , the icons are OK ( the gtk ones are on the systray )
Comment 32 Sebastian Sauer 2008-06-29 22:58:20 UTC
result of today testing; this still seems to be somehow related to bug #153193

The parent window we create using XCreateWindow to work around the crashes in bug #153193 seems to result in auto unmapping those window on XReparentWindow now.

Future testing nm-applet shows that it is one of those apps that crash with a BadWindow-error if the patch from bug #153193 is reverted while other systray's which are displayed correct, don't have that problem if the patch from bug #153193 is reverted.

So, all in all I would not agree that this is a "timing bug in kde4" but we still deal here with broken x.org systray-logic if different visuals are used. Anyway, more testing next days.
Comment 33 Sebastian Sauer 2008-07-01 03:00:16 UTC
Aaron committed a patch with r826530 that *may* fix the issue.
Comment 34 Nicolas L. 2008-07-01 20:42:01 UTC
this is better for me with this commit , gajim appear now, but net_applet and mdkonline still not, i still see their empty space
Comment 35 Aniket 2008-07-02 22:57:03 UTC
I can confirm the bug. Using KDE 4.0.84 on Fedora 9 , the nm-applet for NetworkManager does now show in the systray. 
Comment 36 Sebastian Sauer 2008-07-03 02:42:01 UTC
at least Kubuntu and Arch users could try to open Konsole and "nm-applet" if errors like "nma_dbus_init() could not acquire its service." show up then
vi /etc/dbus-1/system.d/NetworkManager.conf and add;
<policy group="users">
    <allow own="org.freedesktop.NetworkManagerInfo"/>
    <allow send_destination="org.freedesktop.NetworkManager"/>
    <allow send_interface="org.freedesktop.NetworkManager"/>
</policy>
and "/etc/init.d/dbus restart" what seems to fix it but results here in pppd disconnecting and not being any longer able to connect till a restart :-/
Comment 37 Juha Tuomala 2008-07-08 17:26:02 UTC
yep, same here, f9 4.0.84 and no applet visible.
Comment 38 Rex Dieter 2008-07-08 21:47:40 UTC
Per comment #13.

$ xwininfo -tree
(click on plasma systray)
...
        0x1e00415 (has no name): ()  22x22+11+11  +998+780
           1 child:
           0x2600003 "NetworkManager Applet": ("nm-applet" "Nm-applet")  22x22+0+0  +998+780
              1 child:
              0x2600004 (has no name): ()  1x1+-1+-1  +997+779

$ xwininfo -id 0x1e00415

xwininfo: Window id: 0x1e00415 (has no name)

  Absolute upper-left X:  998
  Absolute upper-left Y:  780
  Relative upper-left X:  11
  Relative upper-left Y:  11
  Width: 22
  Height: 22
  Depth: 24
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsUnMapped
  Override Redirect State: no
  Corners:  +998+780  -260+780  -260--2  +998--2
  -geometry 22x22+5-0

$ xwininfo -id 0x2600003

xwininfo: Window id: 0x2600003 "NetworkManager Applet"

  Absolute upper-left X:  998
  Absolute upper-left Y:  780
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 22
  Height: 22
  Depth: 24
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsUnviewable
  Override Redirect State: no
  Corners:  +998+780  -260+780  -260--2  +998--2
  -geometry 22x22+5-0

$ xwininfo -id 0x2600004

xwininfo: Window id: 0x2600004 (has no name)

  Absolute upper-left X:  997
  Absolute upper-left Y:  779
  Relative upper-left X:  -1
  Relative upper-left Y:  -1
  Width: 1
  Height: 1
  Depth: 24
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsUnviewable
  Override Redirect State: no
  Corners:  +997+779  -282+779  -282-20  +997-20
  -geometry 1x1+5-0

Comment 39 Sebastian Sauer 2008-07-09 05:03:21 UTC
Created attachment 25973 [details]
patch that *may* fix it, second try

can anybody confirm that this fixes it? well, for me a blank icon (aka no icon)
is displayed, but at least contextmenu,etc. is available. And don't ask why it
may need a minsize after embedding since I just don't know the answer :)
Comment 40 Sebastian Sauer 2008-07-09 06:44:16 UTC
and for the case the fix does not work as expected, following seems to also provide some kind of result (though then it seems the event->xreparent.parent looses it's position);

bool SystemTrayContainer::x11Event(XEvent *event)
{
    if(event->type == ReparentNotify) {
        XWindowAttributes attr;
        if( XGetWindowAttributes(QX11Info::display(), event->xreparent.parent, &attr) && attr.map_state == IsUnmapped ) {
            XMapWindow(QX11Info::display(), event->xreparent.parent);
        }
    }
    return QX11EmbedContainer::x11Event(event);
}
Comment 41 Helio Chissini de Castro 2008-07-09 18:22:31 UTC
Initial reports are good with latest patch. We have all the the icons back.
The only new issue is that icons are drawing sometimes with garbage pixels ( not only gtk ones, any icon, randomly ), but is minor and is a different issue.
Please commit this patch in branch too and after the rc release we decide if this can be closed.
Thanks for the effort
Comment 42 Sebastian Sauer 2008-07-09 20:19:49 UTC
Could please anybody commit the patch from comment #39 then? I'll not have access to my system till at least tomorrow evening :-/
Comment 43 Aaron J. Seigo 2008-07-10 03:47:03 UTC
re-open if the problem resurfaces. leaving it open until after the rc is asking for it to be forgotten and add to our triage load.

great work, guys! =)
Comment 44 Johannes Simon 2008-08-16 20:52:47 UTC
I still get this issue with nm-applet being autostarted after logging into KDE. Instead of the nm-applet symbol, all I see is a black square. Can't open a context menu either. I'm using KDE 4.1 + Qt 4.4.1.
Comment 45 Rex Dieter 2008-08-16 21:18:33 UTC
Johannes, qt-4.4.1 introduced a regression, which is mostly likely your issue (which is separate than what was addressed here).
Comment 46 Sebastian Sauer 2008-08-17 00:20:55 UTC
Bug 168007 deals with comment #44 and it's fixed in 4.1.1
Comment 47 Johannes Simon 2008-08-17 13:23:59 UTC
Sorry, I can't confirm. Downgrading to Qt 4.4.0 doesn't fix the issue for me, and it only seems to apply to GTK apps, as all the other systray icons (KMail, KMixer, Klipper) do appear after KDE startup.
Comment 48 Sebastian Sauer 2008-08-17 18:44:29 UTC
Johannes: that's with KDE-trunk?
Comment 49 Johannes Simon 2008-08-17 18:49:55 UTC
No, with KDE 4.1.0. But it has nothing to do with bug #168007 and its fix, since this problem also occurs with Qt 4.4.0.
Comment 50 Johannes Simon 2008-08-19 14:30:25 UTC
Ok, I went ahead and installed kde-nightly (with kdebase == r846250), and nothing changed. I think it has something to do with the gnome-keyring asking me to open the keyring. Killing nm-applet and starting it again makes it reappear, as well as logging out and logging into KDE again.

Hope this helps.
Comment 51 Jason Stubbs 2008-11-19 03:35:53 UTC
Is this still a problem with trunk?
Comment 52 Aaron J. Seigo 2008-11-19 04:06:51 UTC
more accurately, does this still happen with KDE trunk and Qt 4.4.3 or better...
Comment 53 Aaron J. Seigo 2008-11-29 02:50:29 UTC
i need someone to test this; if nobody does i'll be closing it when the RC's roll around.
Comment 54 Aaron J. Seigo 2008-11-29 02:53:02 UTC
ah, nmind! i tried the testcase app, commented out the sleep, and it works! wooo for the new systray! =)
Comment 55 Aaron J. Seigo 2009-03-19 20:56:08 UTC
*** Bug 187627 has been marked as a duplicate of this bug. ***