Bug 63216 - gtk2 apps do not stop KDE3 app startup feedback
gtk2 apps do not stop KDE3 app startup feedback
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kdebase (Show other bugs)
8.0
All Linux
low Severity medium
: ---
: ---
Assigned To: Ngo Than
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-11 06:11 EDT by Warren Togami
Modified: 2007-03-26 23:52 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-01 06:20:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Warren Togami 2002-04-11 06:11:11 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
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.
Comment 1 Brent Fox 2002-04-11 11:40:15 EDT
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.
Comment 2 Bernhard Rosenkraenzer 2002-04-11 11:48:29 EDT
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)?
Comment 3 Brent Fox 2002-04-11 12:01:28 EDT
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.
Comment 4 Warren Togami 2002-04-11 16:44:13 EDT
Are there any other GTK2 apps in Skipjack?
Comment 5 Brent Fox 2002-04-11 16:51:36 EDT
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.
Comment 6 Warren Togami 2002-04-11 22:19:25 EDT
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.
Comment 7 Brent Fox 2002-04-16 16:22:34 EDT
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...
Comment 8 Owen Taylor 2002-04-16 16:52:51 EDT
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.

Comment 9 Havoc Pennington 2002-04-16 17:33:25 EDT
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.
Comment 10 Brent Fox 2002-04-16 20:34:21 EDT
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.
Comment 11 Warren Togami 2002-05-09 04:18:02 EDT
Re-tested: Still exists in Red Hat Linux 7.3.
Comment 12 Brent Fox 2002-05-09 12:31:59 EDT
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.
Comment 13 Warren Togami 2002-07-11 23:40:04 EDT
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.
Comment 14 Harald Hoyer 2002-08-05 08:16:33 EDT
hmm, e.g. glade-2 is behaving correctly..
Comment 15 Havoc Pennington 2002-08-05 11:10:14 EDT
glade2 has a window class equal to its executable name, probably...


Note You need to log in before you can comment on or make changes to this bug.