Red Hat Bugzilla – Bug 63216
gtk2 apps do not stop KDE3 app startup feedback
Last modified: 2007-03-26 23:52:44 EDT
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
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):
Steps to Reproduce:
1. Run "redhat-config-users" from K menu or alt-F2 "Run" dialogue.
KDE mouse cursor Application feedback never goes away until it timeouts.
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
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
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 to redhat-config-users.py
- Use g_set_prgname(), if it's bound in Python to tell
GTK+ to use that instead of argv.
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
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
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...