GNOME Bugzilla – Bug 171456
"Keep Above" option in Gimp broken on Win32
Last modified: 2011-11-10 18:12:47 UTC
Please describe the problem: It was indicated to me by a Gimp developer that this bug belongs to GTK+. The docks, toolbox, filter dialogs etc. in the Gimp do not stay above the image windows on the Windows version. In the Gimp Preferences (preferences-->window management-->window manager hints) there is a setting for the behavior for toolbox and docks. There is an option there for "keep above" which I understand was developed to solve this problem in Win32. However, setting this option has no effect. Clicking the image still pops the image window over the toolbox. Steps to reproduce: 1. In Gimp, open or create a new image 2. Move a dock or tool dialog over the image 3. Click on the image. Actual results: the image window pops over the toolbox or dock. Expected results: The Toolbox or dock stay above the image. Does this happen every time? Yes. Other information: From the HIG: "the utility window should be raised above the application when the application window itself is selected from the window list" "Do not place toolboxes in the system window list. Toolboxes should always remain above all primary windows with which they are associated."
Well, if the preferences dialog talk about "window manager hints", this obviously is something quite X11 specific. Still, true, the gdk/win32 backend should try to emulate the same behaviour on Win32. I think there already is a bug open, but couldn't find it right now.
Tor, GIMP uses gtk_window_set_keep_above() here, which is not X11 specific and AFAIK it is supposed to work on Windows.
*** Bug 314327 has been marked as a duplicate of this bug. ***
I'd like to add that in Win32, we're used to all windows/toolbars of a given application sticking together: if the app is minimized, all windows "within" follow suit. If the application is active but another, say FireFox is activated, then all windows fall back one in the stack of active windows; clicking any one of the windows within that app would naturally bring all of that app's windows back to the forefront. Folks like Macromedia take it a step further and actualy hide certain ancillary toolbar windows when the app is not in focus: sometimes this is a be a bit much, because focus is lost in text fields, etc..
Huh? Why was this resolved as fixed? Reopening. Or probably this could be marked as a duplicate of another bug.
Tor, I'm the one who filed the bug. I closed it because checking "toolbox and docks are transient to the active display" now provides this behavior. I tested it on both Windows 2000 and XP. The Windows installer should probably be changed so that on Win32 this is the default, though.
Please note that this is no longer listed as a GIMP bug.
The Fix in Gimp was obnly possible because of a fix in GTK, as far as I know.
*** Bug 394200 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > *** Bug 394200 has been marked as a duplicate of this bug. *** Jo, Michael, I don't understand how it is somewhere people say it's fixed, but I don't find a fix, I read something about "toolbox and docks are transient to the active display" I can't find this option anywhere, where is it located? Kind regards, Henk
Sven says: > Tor, GIMP uses gtk_window_set_keep_above() here Sven, does it really? Doesn't gtk_window_set_keep_above() mean that the window should be above *all* other windows, also those belonging to other applications, even if focus has switched to those windows? I guess the Summary here is misleading, the original poster uses "Keep Above" in a different meaning than GTK+ and X11 does. What the original poster probably means is that it's modalness and/or transient-for that is broken. That is a well-known fact, that whole thing is a mess in gdk/win32, with several more or less duplicate bug reports. Probably this bug can also be marked as duplicate of some other bug.
*** Bug 502310 has been marked as a duplicate of this bug. ***
Yes, GIMP really uses gtk_window_set_keep_above() if the user selects "Keep Above" in the Preferences. This is not the default because it means that the window should be kept above all other windows, also those belonging to other applications, even if focus has switched to those windows. But we offer this as a choice, primarily because there's a GTK+ API for it. Since it doesn't seem to work, it appears that the implementation in the Win32 backend is broken.
Maybe LockSetForegroundWindow() would do the trick here.
*** Bug 513460 has been marked as a duplicate of this bug. ***
Cody, the problem is that gdk_window_set_keep_above() for some reason never is caled with setting=TRUE for a mapped window in GIMP's case. Just for unmapped (freshly created, not yet shown) windows. In that case cross-platform code in GTK+ is supposed to make sure that eventually then once the window is shown gdk_window_set_keep_above() is called again on it. For some reason this doesn't work on Windows. (If gdk_window_set_keep_above() is called on a mapped window, like in testgtk, then it does work.)
Confirming the bug with 2.12.9 and 2.14.3, however it doesn't work for me even after I call show on the window. Here is the test code: #include <gtk/gtk.h> #include <glib.h> #include <glib/gprintf.h> int main(int argc, char *argv[]) { GtkWidget *window; GtkWidget *label; gtk_init(&argc, &argv); window = gtk_window_new(GTK_WINDOW_TOPLEVEL); label = gtk_label_new(g_strdup_printf ("My GTK version is %d.%d.%d", gtk_major_version, gtk_minor_version, gtk_micro_version)); gtk_container_add(GTK_CONTAINER(window), label); gtk_widget_show(label); gtk_widget_show(window); gtk_window_set_keep_above(GTK_WINDOW(window), TRUE); gtk_main(); return 0; }
Fixed in gtk-2-24 branch, will be in 2.24.8 release