Hi! Yesterday I upgraded to gnome 2.18. Since then, gnome-power-manager's icon, which used to be displayed in the notification area has disappeared. I checked that gnome-power-manager is set to "Always display an icon" in Power Management Preferences. Best regards Christian
Please read the GNOME 2.18 Upgrade Guide at http://www.gentoo.org/proj/en/desktop/gnome/howtos/gnome-2.18-upgrade.xml
Same problem with amd64 after update. Portage 2.1.2.12 (default-linux/amd64/2006.1/desktop, gcc-4.1.2, glibc-2.5-r4, 2.6.18-gentoo-r3 x86_64) ================================================================= System uname: 2.6.18-gentoo-r3 x86_64 AMD Turion(tm) 64 Mobile Technology MT-28 Gentoo Base System release 1.12.9 Timestamp of tree: Thu, 23 Aug 2007 18:00:01 +0000 ................ equery gives me => .......... [I--] [ ] gnome-extra/gnome-power-manager-2.18.3 (0) .......... Herman
Issue is still here in 2.20.0. Any ideas for a solution? It's pretty annoying.
No. No one seems to have a clue.
Unfortunately the bug is reproducable on my system too. I don't really know what information can be helpful, my system is up-to-date ~x86.
We need some hardcore debugging here, not information, unfortunately. Well, actually we need information retrieved from some debugging deep in gtk+ and g-p-m internals.. I got somewhere months back but haven't been able to dig even more deeper. I'll try to later dig up the various upstream bugs and link em up from here.
Only say that, if I set up opera browser for opening at gnome-session startup, also its notification icon is usually missing and I have to restart opera for getting it. I am not an expert but, maybe, this would indicate that the problem is more related to notification applet than a gnome-power-manager bug. On the other hand, it's extrange that other icons like beagle or gdesklets one are not affected by this (tomboy usually works but sometime it also fails) :-/
By the way, I've heard about similar problems with Beryl icon in KDE. If beryl-manager is started automatically within KDE startup, there is no icon in the notification area. And of course the icon is on its right place if beryl-manager is started by hand. So maybe Pacho is right and the problem is not in gnome-power-manager itself?
The problem is believed to be in gtk+, but no one knows for sure. It manifests most often in gnome-power-manager.
Created attachment 135258 [details] Hacked ebuild which workarounds this bug Hi guys! I can confirm that this bug is of GTK, as it shows also with tomboy and networkmanager. By the way, at least for gnome-power-manager I think I have found a solution. I noticed accidentally that if g-p-m is emerged without XEvents support (unlike the official ebuild) this bug disappear. More info are available here: http://bugzilla.gnome.org/show_bug.cgi?id=413360#c38 I attach this ebuild which transform xevents support in a use flag. (on my 2007.0 is disable by default) Hope this helps! Cheers! Shogun
(In reply to comment #10) > Hi guys! > I can confirm that this bug is of GTK, as it shows also with tomboy and > networkmanager. No, it's not. It's an application problem if it filters out X Events from under gtk+'s back, as g-p-m did. > By the way, at least for gnome-power-manager I think I have found a solution. > I noticed accidentally that if g-p-m is emerged without XEvents support (unlike > the official ebuild) this bug disappear. > More info are available here: > http://bugzilla.gnome.org/show_bug.cgi?id=413360#c38 Many many many thanks for pinpointing this to the very small HAVE_XEVENTS specific code! I can't believe I didn't find this with my greps back at July when looking for GdkFilter problems (HAVE_XEVENTS code has one). As the functionality this provides has never worked and is probably untested, I went with passing --disable-xevents, but also created a patch that fixes the filter properly and attached it to the above-mentioned bug with a full analysis of why the icon was breaking for those interested. So, this bug is now fixed in 2.20.0-r1, while later we should reconsider if we want to use the xevents functionality or not - awaiting upstreams opinion on the upstream bug
(In reply to comment #11) > So, this bug is now fixed in 2.20.0-r1, while later we should reconsider if we > want to use the xevents functionality or not - awaiting upstreams opinion on > the upstream bug > Could this be also done for 2.18 branch? I know that I can manually edit the ebuild for disabling xevents, but I think that most of users would be happy getting this fixed also for gnome-2.18 :-) Thanks a lot
If all goes well, 2.20 will be going stable in the coming days anyways, so not sure I want a revision bump hanging around that will probably never get stabled
(In reply to comment #13) > If all goes well, 2.20 will be going stable in the coming days anyways, so not > sure I want a revision bump hanging around that will probably never get stabled > OK
I fixed it for 2.18 series afterall in 2.18.3-r1 now.
