GNOME Bugzilla – Bug 128833
Tool dialogs block image (crop tool)
Last modified: 2005-09-16 21:42:17 UTC
Tool dialog boxes pop up in the middle of the image (most annoying when trying to crop) and cannot be sent to the back or otherwise hidden. This seems to be a change since 1.3.22. Could we please change it back?
This is not reproducable here and I would say it's a window manager bug on your side (bug #115092). However since we don't even set the utility window hint any longer, I don't see why this could still happen. Are you absolutely sure you are seeing this in 1.3.23 ??
Now that I think of it I know what is causing this (correct) behaviour. Thanks to the new GimpDialog API the tool dialogs are finally transient to the display window. This is more than correct. What is indeed annoying is that window managers seem to take this hint as a reason to ignore the position that was remembered from the last use of the dialog. Not sure how to proceed from here. On the one hand the transient relationship is correct and should be kept but having the dialog popping up in the middle of the image window is not acceptable.
I don't remember if I read this in the ICCCM or somewhere else, but it was explicitely recommended that all WMs place the windows with a transient_for hint in a way that is relative to the window they are transient for. The idea was that the transient_for hint should be used for temporary dialogs (short lifetime) and should always be displayed above or close to their main window so that the user knows what dialog is related to what window. The relative position (centered, top left corner or attached to one edge) would be set by the WM in order to improve the consistency of the user interface (i.e., all transient dialogs appear in the same way, regardless of the application). From this point of view, it makes sense for the WM to always center the transient window and ignore the specified position. So this is not a bug in the WM: this is a feature that is desirable in most cases. This is done by many WMs, starting with the venerable Motif mwm. And unfortunately, this is not configurable in some WMs. There is not much that we can do about that. Maybe we should not set the transient_for hint? Sigh! :-(
The description in the spec matches our windows very close, so we should set the hint. There is something slightly broken with respect to session management as performed by GimpDialogFactory. This needs to be fixed; nothing more.
This must be fixed before 2.0 as it makes Gimp hardly usable with metacity and other frequently used WMs.
It seems better to set the dialog window transient for the application, and not for the image window... unless it's possible to concurrently have 2 tool windows open on 2 different images. I think in this case the annoyance of a window that won't lower beneath the image window is greater than the semantics of what the window is, and whether window managers are doing the right thing. These windows are clearly not what people had in mind when coming up with the idea of transient_for, and it seems reasonable to me to set them transient on the app rather than the image window. Cheers, Dave.
What exactly would transient to an application mean and how would it be implemented?
I guess by setting the WM_TRANSIENT_FOR hint specifying the toolbox... That would imply, I guess, that the dialog itself would be treated as a _NET_WM_WINDOW_TYPE_DIALOG. Cheers, Dave.
Are you seriously suggesting to set tool dialogs transient to the toolbox window? The only relationship that exists between these two windows is that the toolbox could be considered some sort of leader window for the application. That doesn't make it the transient parent of all windows.
People, please stop confusing things here. There is no fundamental problem. GIMP does the right thing. It marks the dialog as transient and it explicitely sets the screen location where the dialog should show up. This works for most of the time. Only sometimes the position is ignored and the dialog appears centered. This is indeed very annoying and needs to be fixed. But this simply means we need to find out why it doesn't always work and fix it. There's absolutely no need to do any design changes. All we need is a bug-fix.
*** Bug 133699 has been marked as a duplicate of this bug. ***
*** Bug 134768 has been marked as a duplicate of this bug. ***
For what it's worth, I had another look at the ICCCM v2. It is notoriously vague in some areas, and the description of the WM_TRANSIENT_FOR hint is no exception. Here is what is says: ---------- snip ---------- 4.1.2.6. WM_TRANSIENT_FOR Property The WM_TRANSIENT_FOR property (of type WINDOW) contains the ID of another top-level window. The implication is that this window is a pop-up on behalf of the named window, and window managers may decide not to decorate transient windows or may treat them differently in other ways. In particular, window managers should present newly mapped WM_TRANSIENT_FOR windows without requiring any user interaction, even if mapping top-level windows normally does require interaction. Dialogue boxes, for example, are an example of windows that should have WM_TRANSIENT_FOR set. [...] 4.1.10. Pop-up Windows [...] 1. If the window will be visible for a relatively short time and deserves a somewhat lighter treatment, [the X clients] can set the WM_TRANSIENT_FOR property. They can expect less decoration but can set all the normal window manager properties on the window. An example would be a dialog box. ---------- snip ---------- Unfortunately, this does not bring us much further. So we have to look at how various WMs implement this. Many legacy WMs such as mwm (Motif), dtwm (CDE) or 4dwm (IRIX) default to centering the transient window on top of the window that it is transient for, and usually prevent the transient window from being stacked below the main one. I suspect (but cannot check right now) that some of them also decide to ignore the window position supplied by the application if that window is marked as transient. This may be a questionable decision, but it can make sense if the goal is to enforce UI consistency. It would be nice if someone could check what the Ion WM does in this case, because this is a modern WM that is known for trying to improve the UI consistency. Anyway, if such a behavior is observed in several WMs, then we should re-consider the usage of the transient_for hint because having the crop dialog stuck on top of the image window is certainly sub-optimal. But I hope that the cause of the problem is not related to the WM and can be found and fixed somewhere in the GIMP code.
For the most part the Freedesktop WM guidelines were followed for utility dialogs. However, in many cases they don't exactly fit with GIMP window types. In any case, the fact that the ICCCM is vague is not unusual - we are conforming to one interpretation of it for most window types. That said, where that definition causes problems, I'm in favour of going more towards not annoying people than WM spec conformance. Dave.
This is most annoying with the crop tool, so I've added that tool to the description for easy finding the next time. Dave.
*** Bug 136556 has been marked as a duplicate of this bug. ***
Perhaps annoying for whoeever can reproduce the problem. But I am sorry, I cannot reproduce it with 2.0pre4. Sure, the tool dialog is transient to the image window but that is the intended behaviour and I don't see how it is annoying. For me the crop tool works quite well.
Since the problem seems to be highly dependent on the window manager, we should ask some volunteers to test the latest GIMP with as many WMs as possible. I can give it a try with some common Linux WMs such as metacity, sawfish, fvwm, twm, and with dtwm (from CDE), but probably not before next week. It would be nice to have a good coverage of the WMs that are still in use today and check which ones have made the assumption that TRANSIENT_FOR windows should be treated as modal dialogs or something similar. This may be a poor assumption, but the users of these WMs have to live with it and may not have the freedom to switch to a different WM, especially in corporate environments.
#136556 has been marked as a duplicate of this bug(and marked as resolved), however, while i did express an annoyance at the dialogue behaviour in the report, the bug itself was related to the crop tool, not dialogue placement. of course if there's an example above of the issue i reported i'll quite happily shut up ;)
I can confirm that the "tool dialog hiding the image window" behavior occurs in kwm (KDE) and that it is VERY annoying.
You think so? Perhaps we need to add another option to Window management in the prefs dialog then. I find it _VERY_ pleasant that the dialog finally stays on top of the image window whatever I do. I really hated the fact that it was possible to raise the image window above the dialog. That made it impossible to create a crop selection on the image window and keep the dialog visible at the same time.
Let me explain my annoyance a little more clearly... In Gimp 1.2, I would select the crop tool and start to draw the rect. The crop dialog would usually pop up somewhere else on the screen. Normally, I'd ignore it, refine the rect, and then click inside to perform the crop. If I couldn't ignore it, I'd focus the image (pehaps covering the dialog), and continue. In Gimp 2.0, I again select the crop tool and start to draw the rect. As soon as I start, the dialog pops up on top of my work, covering where I'm drawing the rect. I have to stop, move the box (often to the edge of the screen) and continue on as before. Now, most often I'd like to just ignore the crop dialog. (I understand its utility in some situations.) The "transient problem" is even worse with tools like "curves" or "levels" when the dialog covers the very pic I'm trying to tune. So every time I have to manually move the dialog out of the way. This is especially bad on small images. An option in the prefs is a reasonable compromise, I guess. I'm not sure Joe User would not have trouble finding it, however. Perhaps the option could be supplemented with a "Keep on top" check box on the dialog itself, which sets the option for the user. I've no idea how realistic this is to code. I'd suggest that if an option is used, the Gimp 1.2 behavior would be the default.
I am attaching a patch that disables the transient relationship for the following tool dialogs: - all image_map (color correction) tools - crop tool - all transform tools It keeps the current behaviour for the following tools: - measure tool - color picker I would suggest we apply this patch for 2.0. It remains to be discussed if it's OK to keep the behaviour for the measure and color picker tools. IMO it is important for these two tools to keep the (small) tool windows over the image window.
Created attachment 25641 [details] [review] suggested fix (or workaround)
The above patch crashes on me with (gimp:24170): Gimp-Widgets-CRITICAL **: file gimptooldialog.c: line 65 (gimp_tool_dialog_new): assertion `GTK_IS_WIDGET (parent)' failed (gimp:24170): GLib-GObject-WARNING **: invalid (NULL) pointer instance (gimp:24170): GLib-GObject-CRITICAL **: file gobject.c: line 1619 (g_signal_connect_object): assertion `G_TYPE_CHECK_INSTANCE (instance)' failed Program received signal SIGSEGV, Segmentation fault. 0x08111b35 in gimp_image_map_tool_initialize (tool=0x8eb1e18, gdisp=<incomplete type>) at gimpimagemaptool.c:237 237 gtk_container_add (GTK_CONTAINER (GTK_DIALOG (shell)->vbox), vbox); (gdb) print shell $1 = (GtkWidget *) 0x0
Oops, sorry. Of course gimp_tool_dialog_new() should accept a NULL parent. Fixed in CVS: 2004-03-14 Sven Neumann <sven@gimp.org> * app/widgets/gimptooldialog.c (gimp_tool_dialog_new): allow to pass NULL as parent widget.
This looks like the right thing to do to me, at least for the time being. I think we can mark this as fixed once the patch has been tested (which I haven't done yet). Cheers, Dave.
I decided that it's better to do it consistently and not to special case some tools: 2004-03-14 Sven Neumann <sven@gimp.org> * app/tools/gimpcolorpickertool.c * app/tools/gimpcroptool.c * app/tools/gimpimagemaptool.c * app/tools/gimpmeasuretool.c * app/tools/gimptransformtool.c: don't set tool dialogs transient to the image window. Fixes bug #128833.
Reverted part of this change in the HEAD branch: 2005-09-16 Sven Neumann <sven@gimp.org> * app/tools/gimpimagemaptool.c (gimp_image_map_tool_initialize): set the imagemap tool dialogs transient to the image window. See comments in bug #316521.