Bug 62308 - GTK misbehavior in KDE window manager
GTK misbehavior in KDE window manager
Product: Red Hat Public Beta
Classification: Retired
Component: gimp (Show other bugs)
All Linux
high Severity medium
: ---
: ---
Assigned To: Matt Wilson
David Lawrence
: 62905 (view as bug list)
Depends On:
Blocks: 61590
  Show dependency treegraph
Reported: 2002-03-29 09:24 EST 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:
Last Closed: 2002-04-17 16:16:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Warren Togami 2002-03-29 09:24:20 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020314

Description of problem:
When you right-click a GIMP canvas and select File - Save-As, the Save-As
dialogue doesn't appear because it appeared below the canvas.

Version-Release number of selected component (if applicable):
Skipjack beta1 with up2date (3-27-2002)

How reproducible:

Steps to Reproduce:
1. Make a gimp canvas (maximize this window for best bug results).
2. Right click anywhere within that canvas and Save-As.
3. Where is the Save-As dialogue?

Actual Results:  Save-As dialogue popped-under the canvas, appearing as if
nothing happened.  (Tested in KDE.)

Expected Results:
Two possible fixes:
Save-As dialogue should pop up in front of the canvas.
- OR -
Add 50 IQ points to all users.
One fix is easier than the other...
Comment 1 Matt Wilson 2002-04-01 11:03:37 EST
it sounds like the KDE window manager isn't properly honoring WM hints.
Comment 2 Warren Togami 2002-04-07 23:03:42 EDT
I suspect that Bug 62905 is a duplicate of this KDE misbehavior.  
redhat-config-users exhibits this behavior where the new dialogue window  
appears under the current window when used within KDE.
Comment 3 Brent Fox 2002-04-09 14:29:02 EDT
*** Bug 62905 has been marked as a duplicate of this bug. ***
Comment 4 Bernhard Rosenkraenzer 2002-04-10 05:18:39 EDT
Comment from base maintainer: 
I can see what happens, I can't really imagine how to fix this: 
- the save as dialog of gimp is a standalone window, which means it is not a 
transient for, as most dialogs should be -> Bug in Gimp 
- kwin of the KDE-3 includes a long requested feature that windows don't popup 
on top of a window currently getting input. The "timestamp zeroed by 
keyboard+mouse event" mechanism takes into account as a special case the 
transient_for windows (most often dialogs). 
I don't see (using xprop on the save as dialog of Gimp) any WM hint that KWin 
should take care of and it doesn't. Please spot it to me, if I'm missing 
Gimp bug?
Comment 5 Warren Togami 2002-04-10 05:40:32 EDT
Not limited to Gimp.  Other GTK+ programs like redhat-config-users suffers from
this behavior.  Please read Bug 62905.

All I know is that both programs behave as expected in Gnome but not KDE. 
Perhaps it is not a KWin bug, but rather those programs are simply lacking WM
hints and Sawfish simply takes care of those cases implicitly?

Perhaps KWin in KDE 2.x handles this implicit cases, but KDE3 it no longer does.
 If this is so, then there may be a great many more programs that need explicit
fixing... =(
Comment 6 Bernhard Rosenkraenzer 2002-04-10 05:54:49 EDT
I've verified xprop doesn't show any hints KWin doesn't respect, so this seems to be GTK 
Correct me if I'm wrong, I'm not really an Xlib or X protocol expert.
Comment 7 Owen Taylor 2002-04-15 08:26:26 EDT
It's really hard to say what's going on here, but it's incredibly
unlikely it has anything to do with GTK+... most likely all
that's going on here is a poor choice on the part of KWin; it
probably is deciding that sinc ethe window isn't "transient for"
the currently focused window, the user doesn't want to see it.

It's probably a 10 second fix to make redhat-config-users set
the transient-for hint properly, the GIMP mau be harder to fix.

(But I don't think kwin should be putting the window behind
even if it isn't transient for... think of a dialog from
another application.)

It's possible there is something more subtle going on and the
problem is that KWin, unlike other window managers, isn't honoring
the XRaiseWindow, in GTK+'s:

      XRaiseWindow (private->xdisplay, private->xwindow);
      XMapWindow (private->xdisplay, private->xwindow);

But that would only be the case if the problem occurred only with
the second time the dialog was brought up.

Comment 8 Bernhard Rosenkraenzer 2002-04-15 09:01:54 EDT
Assigning to redhat-config-users so the WM hint can be set properly.  
(I'm sure kwin does honor XRaiseWindow).  
Comment 9 Havoc Pennington 2002-04-15 09:36:31 EDT
Windows XP uses the same algorithm as kwin, however, on Windows I think 
dialogs can be more reliably recognized and treated differently (they always
come up on top). On X it's not nearly so reliable that a dialog will be properly
marked. Though it should be.
Comment 10 Brent Fox 2002-04-16 16:31:37 EDT
Well, I've added the fix that allows redhat-config-users to work correctly:
+            self.groupProperties.groupWin.set_transient_for(self.toplevel)

I don't know what to do with this bug at this point, but at any rate it doesn't
have anything to do with redhat-config-users anymore, but the larger problem
still exists.  So, I'm changing the component to gimp so maybe someone will fix it.
Comment 11 Bernhard Rosenkraenzer 2002-04-17 16:16:29 EDT
kwin in kdebase 3.0.0-12 has a tweak to fix this.  
I still think a WM hint should be set because we  
shouldn't rely on hacks in window managers to get the  
correct behavior, but since it currently shows up 
correctly in both desktops, I think this can be closed 
for now (or have the 61590 state removed).
Comment 12 Warren Togami 2002-05-09 04:35:07 EDT
Confirmed, appears to be fixed in Red Hat Linux 7.3.

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