From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020405 Description of problem: Within KDE, redhat-config-users when run from the K menu or alt-F2 "Run" box does not stop the KDE mouse cursor application startup feedback once the window has opened. I suspect that redhat-config-users is missing some type of hint that signals a stop to startup feedback in KDE. I have tested those other python + GTK programs, and they don't exhibit this minor problem. Version-Release number of selected component (if applicable): redhat-config-users-1.0-[8-12] How reproducible: Always Steps to Reproduce: 1. Run "redhat-config-users" from K menu or alt-F2 "Run" dialogue. Actual Results: KDE mouse cursor Application feedback never goes away until it timeouts. Expected Results: Application startup feedback should stop when the program window opens.
Bero, any idea why this would happen? As far as I know, redhat-config-users is the first gtk2 app in the distro, so that might explain why no other apps have this behavior.
The KDE app startup feedback usually stops when the application opens an X window - does gtk2 do any odd things when opening a window (such as passing special WM hints)?
Not as far as I know. The cursor will go away eventually (I guess it times out or something). The GTK guys here tell me that GTK isn't passing any special WM hints, so I don't know what the problem is.
Are there any other GTK2 apps in Skipjack?
Well, userhelper is in gtk2, but it's only launched as a way of letting you enter the root password to run a root-only app. As far as I know, nothing besides redhat-config-users and userhelper use gtk2.
May be something new in gtk2 that gtk1 handled differently. When I run neat via userhelper in KDE the startup feedback doesn't stop when userhelper pops up. It stops when neat (gtk1) pops up.
I have no idea what's going on here. Owen and Havoc, any input here? At any rate, I don't think that the bug lies with redhat-config-users...
If I compare xprop results on neat and redhat-config-users, the main difference I see is that the class for redhat-config-users come up as: redhat-config-users.py I think the problem is most likely the sh wrapper around redhat-config-users. So, your choices from the GTK+ end are either to: - Figure how to get the right argv[0] to redhat-config-users.py - Use g_set_prgname(), if it's bound in Python to tell GTK+ to use that instead of argv[0]. It may be possible that there is some more reliable way within the framework of the KDE app start notification to make the launcher / app connection than the class matching it is apparently using now.
IMO it's a KDE bug if KDE tries to do launch feedback for apps that don't specifically request it in their .desktop file, because said launch feedback can't be reliable.
otaylor, but I have the same kind of shell wrapper around dateconfig, and it does not display this behavior. I can't imagine why redhat-config-users would act differently. It did not show this behavior until the port to GTK2. I tend to agree with hp on this, though. It's sort of silly to have the launch feedback thingy run for apps that don't need (or want) it.
Re-tested: Still exists in Red Hat Linux 7.3.
I'm going to change the component of the bug to KDE. redhat-config-users doesn't know anything about the KDE launch feedback, so whatever the KDE launcher thing is trying to do, it's doing it wrong. I can verify that some of my other GTK2 apps I'm working on that didn't ship in 7.3 display the same behavior, so maybe the bug is with GTK2...I can't say for sure.
Re-tested: Still exists in Limbo beta. This is even worse now due to the higher number of gtk2 applications. I still think this is a gtk2 quirk.
hmm, e.g. glade-2 is behaving correctly..
glade2 has a window class equal to its executable name, probably...