Bugzilla Bug 188618

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 an attachment (id=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.