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: Always 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...
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 something. Gimp bug?
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... =(
I've verified xprop doesn't show any hints KWin doesn't respect, so this seems to be GTK misbehavior. 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 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.
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: + 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.
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.