Comment 31 for bug 213494

Andrew, it actually sounds like the same issue, generalized.

The way I see it, the issue goes like this:

Gnome panel starts the applets too early. Glipper is "lucky" enough to start faster than the rest of the applets, so it fails to start almost every first login after powering on the system. If you log out and log back in again, most of the stuff is already in RAM, and Gnome starts a lot faster, enough for the issue to no longer reproduce.

The "sleep(8)" workaround mentioned above delays the startup of glipper. That, the way I see it, delays glipper enough so Gnome panel can set up its things. Well, until you get Gnome to start even more slowly, like I did, in which case that sleep(8) doesn't fix the issue (unless you increase it to a bigger value), and you get the failure to start again. That's what happened to me anyway.

One day, after I had glipper removed, Gnome decided to take a heck of a lot more time to boot. The effect? The same bug reported for glipper here manifested for most of the other applets. That means I was kindly offered to delete everything from the menu to the clock applet :) This happened only once, but I think I can add something that can slow down gnome panel's startup time and reproduce this issue reliably.

I also took a crash course in python the past few days, and glipper's code doesn't seem to have any bug related to its startup problem in it. The problem can occur in the bonobo initialization part, which is outside of glipper's control. I didn't read all the code though, so I can't say 100% sure that what I just said is right, but chances are high that it is.

This makes me think that this bug should be renamed and assigned to gnome panel.

Can you see my logic in here? I hope I'm not too far off from the truth.