Bug 164786

this seems only related to perl_gtk applications.
All was ok with kde 4.0.x

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 :)

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?

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

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?

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 ?

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 ***

it do not seems to be the same as bug 164656

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 :)

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.

Fwiw, nm-applet (aka NetworkManager-gnome) does the same thing, leaving a blank entry in systray, at least until I restart plasma.

reopening

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 :)

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

just tested your workaround and this works for me too :)

Map State: IsUnviewable

so, we try to embedClient to early...

just for info, after your workaround, Map State is now :

Map State: IsViewable

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.

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?!

re comment #19; ah, no. Qt does destroy it. So, it's not that easy :-/

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

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.

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 :)

for me this is still valid with this patch. I have this behaviour with apps like Gajim when it starts with KDE

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 :-/

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?!

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 ?

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).

tried patch from comment #22, didn't help here with nm-applet (NetworkManger-gnome) (from comment #11)

sorry, meant to include too that remove systray, add systray, it does (re)appear.

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 )

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.

Aaron committed a patch with r826530 that *may* fix the issue.

this is better for me with this commit , gajim appear now, but net_applet and mdkonline still not, i still see their empty space

I can confirm the bug. Using KDE 4.0.84 on Fedora 9 , the nm-applet for NetworkManager does now show in the systray. 

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 :-/

yep, same here, f9 4.0.84 and no applet visible.

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

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 :)

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);
}

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

Could please anybody commit the patch from comment #39 then? I'll not have access to my system till at least tomorrow evening :-/

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! =)

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.

Johannes, qt-4.4.1 introduced a regression, which is mostly likely your issue (which is separate than what was addressed here).

Bug 168007 deals with comment #44 and it's fixed in 4.1.1

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.

Johannes: that's with KDE-trunk?

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.

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.

Is this still a problem with trunk?

more accurately, does this still happen with KDE trunk and Qt 4.4.3 or better...

i need someone to test this; if nobody does i'll be closing it when the RC's roll around.

ah, nmind! i tried the testcase app, commented out the sleep, and it works! wooo for the new systray! =)

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