Can you get the "gnome-power-manager --verbose --no-daemon" output on login please, i.e. where no icon is shown.

Thanks.

I.e. in session configuration. I'll send it when I relog.

Created attachment 83774 [details]
grep gpm .xsession-errors

Unfortunatly when I tried to add strem redirection it worked ok.

I need the log on a failed startup else it's impossible to debug. Thanks.

It creates no file with redirection - sorry (and after restart it's always ok).

Created attachment 84499 [details]
gnome-power-manager --verbose

I guess it could be this

Sorry I forgot to change NEEDINFO

>[get_stock_id] gpm-tray-icon.c:680 (15:09:46):	 Trying CRITICAL icon: primary, ups, mouse, keyboard
>[get_stock_id] gpm-tray-icon.c:704 (15:09:46):	 Trying CHARGING icon: primary, ups
>[get_stock_id] gpm-tray-icon.c:721 (15:09:46):	 Trying PRESENT icon: primary, ups
>[get_stock_id] gpm-tray-icon.c:731 (15:09:46):	 no devices present, so no icon will be displayed.
>[gpm_tray_icon_sync] gpm-tray-icon.c:763 (15:09:46):	 Going to use stock id: (null)

That's the reason. I'm not sure why. I'll test it on VMWare tonight.

Okay, I used to have this problem and after this bug I tried a few things to get rid of it. It seems like if I remove power related applets from my panels (inhibit, cpu scale, etc.) then the notification icon magically works on login. Strangely enough, if I add the applets back, it still works.

I guess what was happening was that the power-related applets were starting the manager before the notification tray applet started. I think this is related another bug trying to fix a problem with restarting the panel and making the power manager icon add itself back.

Ahh, that could be it. g-p-m auto-starts if you start a program that uses the interface so there could be a race here.

Can you try to do "rm /etc/dbus-1/system.d/gnome-power-manager.conf" as root and then try to reproduce?

Cheers for debugging this.

Okay, scratch my speculation above about applet loading order. The problem seems to be gnome-session starting gnome-power-manager via .config/autostart. Also, the bug I was talking about was bug #375377

This happens to me, too. Gentoo 2006.1 with GNOME 2.18

David/Paolo, could you try trunk for me please? I've got a few fixes in there that might need backporting. Thanks.

Still Gentoo 2007.0 with Gnome 2.18.1 and GPM 2.19.1

It is still there, I'm using Gentoo, with Gnome 2.19.5 and gnome-power-manager 2.19.5.
I think it is some kind of race condition, using a session script that adds a "sleep X" (i use "sleep 15") before g-p-m solves it for me.

Richard need more info about this bug ? The only way to work around this is to kill g-p-m and then restart it again after the gnome-session load. I would like to backport this fix if it's fixed on trunk to 2.18 so we can merge it on our stable release at Gentoo.

According to my debugging this seems more of a GtkStatusIcon or notification area bug.
In case of the g-p-m icon, it doesn't handle the PropertyNotify on the X Selection for the notification manager deep down in GtkStatusIcon code (actually lower-level gtktrayicon-x11.c backend code) or it just isn't notifying for some reason (if it isn't selected or anything like that).
I'll try to look into this further again later this week, but I'd appreciate any help.
There are also some other bugs (most filed against gtk+) that possibly describe this very same issue.
I'll provide bug numbers for those soon, and some additional information I gathered during GUADEC as soon as I can reserve some time for doing so.
By the way, in Gentoo we can also reproduce the problem by removing the notification area applet and re-adding it.

I can confirm that removing the notification area and then re-adding it results in gnome-power-manager's icon vanishing. Can't say whether that's due to a Gentoo  issue (we must be doing _something_ wrong) or gnome-power-manager issue, but it's definitely reproducible and still extant (ie, I still have to kill gnome-power-manager manually every time I log in if I want to see the icon).

Interestingly, gnome-power-statistics still reports data even though the icon isn't there. Unfortunately, when I go off AC and want the icon up & subsequent notifications, killing gnome-power-manager loses history data, which is a bummer.

[So glad there's a bug open about this; I was wandering around GUADEC like a lost puppy trying to find someone who knew about this]

AfC

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

It records data because it is there. On my laptop it hides behind the gnome foot icon on the left top side of the screen. I know it because when i unplug the cable or the battery is too low the messagebox appears there.

I hope there will be a solution soon.

*** Bug 474321 has been marked as a duplicate of this bug. *** was mine.

Cheers!

<If we can't fix it, it ain't broke>

Same bug here, even with freshly released gtk+ 2.12.0. That's a blocker for 2.20 IMHO.

(In reply to comment #22)
> Same bug here, even with freshly released gtk+ 2.12.0. That's a blocker for
> 2.20 IMHO.

Is this just a gentoo issue?

(In reply to comment #23)

> Is this just a gentoo issue?

Not anymore. How can I help debugging it?

Fixed in 2.19.92 or I've been being lucky?

I think you've been lucky; it's still failing for me in 2.19.92.  I'm upgrading to 2.20.0 now, we'll see if it still happens there.

In 2.20.0 I can't reproduce the bug. But when I mark this bug as fixed I will reproduce it ;)> 

PS. What information is needed? I'm lost.

2.20.0 got same issue.

...and it seems to be only g-p-m issue. Other notification area guests like Pidgin are not affected. Even after removing notification area applet from panel and re-adding it Pidgin icon appears again. g-p-m icon stays invisible until g-p-m is restarted or display policy is changed.

Reopening based on comment #24...
Though I still think this is a GtkStatusIcon issue in gtktrayicon-x11.c that is a corner case that happens through the way g-p-m uses the control.

I'm willing to sit down with someone and go further from my investigations in comment #18. I suppose that would be useful with someone who is actually experiencing the problem.
In Gentoo Linux we don't patch things much on top of release tarballs - maybe some patch in Fedora or elsewhere is making the problem not happen as a side effect?

Well. OK I actually can reproduce it from time to time.

I have the same problem with tomboy, under Gentoo and gnome 2.18

Similar bug in:
https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/123390

If you need some info feel free to ask me for that

Thanks

Maybe, would this be related with bug 424618 ?

I have exactly the same problem with opera browser if I set it for launching automatically by gnome-session at login, maybe a task applet problem?

Created attachment 98035 [details]
Script which resolve this bug with an ugly hack

Hi!
I also have this bug with GNOME 2.20.1 on Gentoo 2007.0.
While waiting for this resolution I wrote a simple script.
This script basically waits until gnome-panel starts. Then it waits another 5 second to ensure that the notification area have been loaded.
At the end it kills any existing instance of g-p-m and finally it launchs g-p-m again.
Obviously user must add this to startup application in session properties.
Hope this helps.
Best regards.
   Shogun

Hi guys...
I continued investigating on this bug...
On my system, a Gentoo box, I noticed accidentally that this bug disappear if g-p-m is compiled without XEvents.
Looking the Changelog, I saw that XEvents was introduced in 2.17 series, that is when this bug appeared on my box, so I think I have found the problem.
I looked up the code to see how XEvents is related to the bug, but the switch in the configure script seems to affect only gpm-button.c, so I couldn't figure it out.
Maybe you g-p-m developers can finally resolv this?
Cheers!
  Shogun

>this bug disappear if g-p-m is compiled without XEvents

Good detective work - now the real quest is to find out *why* this causes the bug :-)

I'll have a look this weekend, if nobody beats me to it.

XEvents code sounds like something that might be touching the X event filters to somehow disable the filter that gtktrayicon-x11.c relies on - might want to look into code paths in xevents specific code that might do it

Created attachment 98803 [details] [review]
Fix the XEvent handling in gpm_button_filter_x_events

gpm_button_filter_x_events had all the key handling code inside the following if condition:
if (xev->type != KeyPress)
which is obviously wrong (should be == not !=), as if the XEvent type isn't KeyPress or KeyRelease, then xkey.keycode and xkey.state do not contain valid values. The patch changes the logic to first return GDK_FILTER_CONTINUE if it isn't a KeyPress, to let the event propagate up to gtk+ and the previously wrongly conditioned code is out of the condition, as at that point it's guaranteed it's a KeyPress - the returning before also ensures we don't stump on bad memory with the "keycode" and "state" variable assigning and is how gnome-control-center-2.18 did it for multimedia keys.

The bug of icon not appearing happened because addition of notification-area-applet generates an X Event for notification-manager ownership change, and the bug in gpm_button_filter_x_events didn't allow gtktrayicon-x11.c to see the event due to the propagation stopping from GDK_FILTER_REMOVE being returned on all non-keypresses.

So since the addition of --enable-xevents, all it did was stop the gpm tray icon from appearing on startup, as keypresses were never processed on a real keypress of the power management keys, so this codepath is probably completely untested. I might add that usually these keys work anyhow through other codepaths, so I'm not sure if for Gentoo we should include the patch to get the xevent functionality or just disable xevents until it's more tested

Additionally maybe GDK_FILTER_CONTINUE should be returned (and not leaking hashkey) for "Key '%s' not found in hash!" case as well, to pass normal keypresses on, which might help with accessibility access to the icons context menu via only the keyboard. Not exactly sure though

Mart! Well done! I've committed this to trunk (with your second suggestion also), could you please verify it works and then I'll push to 2-20 stable also:

2007-11-09  Richard Hughes  <richard@hughsie.com>

	* src/gpm-button.c: (gpm_button_filter_x_events),
	(gpm_button_grab_keystring), (gpm_button_button_key):
	Properly process the GdkXEvent so we don't hide the GtkStatusIcon
	when we compile with --enable-xevents.
	The bug of icon not appearing happened because addition of
	notification-area-applet generates an X Event for notification-manager
	ownership change, and the bug in gpm_button_filter_x_events didn't allow
	gtktrayicon-x11.c to see the event due to the propagation stopping from
	GDK_FILTER_REMOVE being returned on all non-keypresses.
	This is a slightly modied patch from Mart Raudsepp, many thanks.
	Fixes #413360

Created attachment 98805 [details] [review]
Patch that was committed

Here's the patch that you committed to SVN, in case it's useful to anyone before a tarball gets released with a fix.
I think I was wrong in the accessibility concerns, as I didn't notice it's setting up the filter on the root window (just as gtktrayicon) and not the icon that could use some normal keypress handling.
I can't actually test if the keypress handling works and I'm concerned about this from downstream perspective.
I'll test if the icon works on notification applet remove/readd with this patch in a moment

The icon appears good with the committed to trunk patch with --enable-xevents applied to 2.20.0.
However I don't see any debug messages from any keypresses still with gnome-power-manager --no-daemon --debug=power, so not sure if the "xevents" functionality itself works.

Btw, the handling of HAVE_XEVENTS is a bit interesting - there's a runtime gboolean have_xevents in gpm_button_init that gets set to TRUE if HAVE_XEVENTS is enabled, when it could instead wrap the gpm_button_button_key, gdk_window_add_filter call and the callback handler (gpm_button_filter_x_events) inside #if HAVE_XEVENTS for some trivial code size win in the default --disable-xevents case.

Hi...I'm a newcomer to Linux and I'm not sure how to resolve this issue. I'm running gnome 2.20 on ubuntu 7.10 (gutsy)....i'm not really sure how I edit the "gpm-button.c" file since I can't find it...is there a package i have to install to access this file?...Any help is greatly appreciated. 

(In reply to comment #46)
> Hi...I'm a newcomer to Linux and I'm not sure how to resolve this issue. I'm
> running gnome 2.20 on ubuntu 7.10 (gutsy)....i'm not really sure how I edit the
> "gpm-button.c" file since I can't find it...is there a package i have to
> install to access this file?...Any help is greatly appreciated. 
> 

1. If you really want compile from source.
2. Wait untill update for ubuntu will appear (strongly recommended).