Red Hat Bugzilla – Bug 62308
GTK misbehavior in KDE window manager
Last modified: 2007-03-26 23:52:21 EDT
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)
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.)
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...
it sounds like the KDE window manager isn't properly honoring WM hints.
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.
*** Bug 62905 has been marked as a duplicate of this bug. ***
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
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
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.
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
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.
Assigning to redhat-config-users so the WM hint can be set properly.
(I'm sure kwin does honor XRaiseWindow).
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.
Well, I've added the fix that allows redhat-config-users to work correctly:
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.
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).
Confirmed, appears to be fixed in Red Hat Linux 7.3.