Hey, I have a Debian user reporting a weird problem between xfpm and awesome systray. Basically, every time he suspends/resumes, the plugin takes twice the place in the systray. As it doesn't happen with xfce4-panel, it seems related to awesome, but it's not sure what it's linked to. Upgrade logs shows that the user updated xcb-util packages around that time so it might be related but I'm out of ideas on how to debug this, so any help would be welcome. Downstream bug is at http://bugs.debian.org/626224
This also happens with the fluxbox window manager.
I can confirm the bug is definitely _not_ only an issue with awesome. I am using Openbox (3.5.0) with tint2 panel (0.11 svn) under an xfce4 session (4.8) on a Debian system. When the xfpm icon is displayed in the panel, after resume from suspend/hibernation the xfpm "re-initializes" and creates a "new" icon in the panel leaving an unused blank space. As someone in the downstream Debian bugzilla stated, there is an observable second-or-two gap when, after resume from suspend, you can actually see as the "another" icon appears and leaves a blank space. The blank icon space disappears either after killing and relaunching tint2 _or_ by calling "xfce4-power-manager --restart". Both methods work. The problem is obviously not awesome specific (the title of the bug report should be changed). Best regards, Jan Jansky PS: there was other similar issue with gnome-power-manager and tint2 leaving a blank space in the panel (see here https://bbs.archlinux.org/viewtopic.php?id=104600)
I have this same problem on fedora 16, xfpm 1.0.10. When i run xfce4-power-manager --restart the "blank icons" disapear.
I've noticed the same problem also with trayer (and with awesome as well). Restarting awesome or trayer doesn't help, xfce4-power-manager --restart helps. This problem is now reported for awesome, tint2, fluxbox and trayer, so the title of the bug report should be changed.
Suspend/resume is not needed to trigger the bug. Simply (physically) removing and reinserting the battery produces the undesired behavior (one empty space for each action).
Created attachment 4243 Fix empty systray icon in some panels on battery removal and addition 1.) Please test this patch. 2.) Is it the correct fix? It appears destroying a GtkStatusIcon should be enough to remove it from the tray. Yet that is not the case with the trays mentioned in this bug (add lxpanel to the list). So, should the trays be doing something different, or is this patch correct?
(In reply to comment #6) > Created attachment 4243 > Fix empty systray icon in some panels on battery removal and addition > > 1.) Please test this patch. > > 2.) Is it the correct fix? It appears destroying a GtkStatusIcon should be > enough to remove it from the tray. Yet that is not the case with the trays > mentioned in this bug (add lxpanel to the list). So, should the trays be doing > something different, or is this patch correct? Worked as expected for me on fedora 16 x86_64. Thanks!
Hey! I've been chasing this bug over the last week, and just today started looking for a way to submit the fix. Sadly, it seems I'm late for just one day ^^' But I guess it's cool that it is fixed anyway (my fix was the same, setting the icon visibility to FALSE before destroying the struct). For next time, what's the common "protocol" to submit a patch? Just by attaching it here, it will be taken into account? I'm just starting "collaborating" in this way, so any insight will be appreciated. Thanks!
(In reply to comment #8) > Hey! > > I've been chasing this bug over the last week, and just today started looking > for a way to submit the fix. Sadly, it seems I'm late for just one day ^^' But > I guess it's cool that it is fixed anyway (my fix was the same, setting the > icon visibility to FALSE before destroying the struct). Hehehe... :-) Maybe you can add a Signed-off-by line like they do with the kernel? Good to know somebody else arrived at the same fix independently. Do you know why destroying a GtkStatusIcon is not enough to make it disappear entirely? I am thinking there may be a memory leak here. To test this I modified the GtkStatusIcon tutorial from the gnome site to add and remove a status icon 5 times a second. The rss and vsz memory sizes increase in steps, on average linearly with time. You can get it here: http://astro.uni-tuebingen.de/~gebhardt/gtk-status-icon-test.c and a script to measure the vsz memory usage: http://astro.uni-tuebingen.de/~gebhardt/mem_plot.sh This also happens using xfce4-panel. I don't know what to make of this. Is this a GTK+-2 bug? Should I file it elsewhere? > > For next time, what's the common "protocol" to submit a patch? Just by > attaching it here, it will be taken into account? I'm just starting > "collaborating" in this way, so any insight will be appreciated. This is also my first time contributing to xfce. Is there any other place the patch should be advertized?
Nope, I don't have any idea as of why it would not be enough, but I noticed it was done for the adaptor icon so I figured I would just try with this one too. Just for curiosity I tried your test and reproduced the problem, memory usage gets higher and higher as long as the calls are made. The weird thing is that it increases only every some seconds, and not immediately after each call... maybe is just a delay on the process monitoring mechanism? Anyway, do you know where does your patch go now that you posted it here? I have already temporarily fixed it on my system, but it would be nice to see it included soon in one of the next Arch package updates I run.
Created attachment 4248 Patch to avoid warnings when calling xfpm_battery_notify_idle with an invalid data pointer If two battery added/removed notifications happen very fast, the xfpm_battery_notify_idle callback set up to run with the recently added battery object as a parameter may be run after the new battery has already been destroyed. One possible fix is this one: to check for a valid object before invoking the xfpm_battery_notify. The other one would be unregistering the callback, be it that it was already called and unregistered, or still hasn't.
Sorry for the noise, I'm just just understanding how bugzilla works ^^' The bug my previous patch fixes is not directly related to this one, but I run into it by debugging the one this report refers, maybe there's no need to open another ticket and can be applied as well. And my memory failed in my previous comment Henry, the adaptor icon wasn't being set to visible-FALSE either, as I realized from taking another look at your patch.
*** Bug 8424 has been marked as a duplicate of this bug. ***
It seems that the patch attached to the Debian bug at http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=156;filename=09_fix-insert-battery.patch;att=1;bug=626224 fixes the issue for at least some people. I never was able to reproduce it so I can't confirm it works but at least it doesn't break.
(In reply to comment #14) > It seems that the patch attached to the Debian bug at > http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=156;filename=09_fix-insert- > battery.patch;att=1;bug=626224 fixes the issue for at least some people. That is good news! It is the same patch as the one attached to this bug.
Nick, seems that you commited a patch to xfpm, can you take a look at this one and commit it? Thanks!
As the trayicon has been replaced by a panel-plugin in git master, this bug no longer applies.