GNOME Bugzilla – Bug 159359
Utility windows are never and cannot be minimized
Last modified: 2020-11-07 12:35:40 UTC
In Gimp, I can set the docks to become utility windows. Unfortunately, Metacity doesn't allow me to minimize utility windows, so the Gimp docks stay visible no matter what. I think utility windows should be minimized when all other windows in the application are minimized too. After all: utility windows are almost useless without the main window.
Created attachment 34098 [details] [review] Patch to implement this feature.
Created attachment 34101 [details] [review] Correct patch
The semantics of a utility window is that it's a small, transient window associated with a document window. As such, a utility window should be minimized if and only if its parent window is minimized. In the GIMP, all those tool boxes and such are NOT utility windows according to the agreed-upon specification.
? In Gimp: - Create a dock window. - File->Preferences->Window Management->Window Type Hint for the Docks: Utility Window - Restart Gimp. That looks very clearly like a utility window to me. It has the "utility" window hint, it has a slightly smaller title bar, it's not minimizable, it's raised when one of the other Gimp windows are raised. How can it not be a utility window?
Yes, Gimp is not following the specification. You're right. Please report this bug to the gimp authors.
I filed bug #159378 http://bugzilla.gnome.org/show_bug.cgi?id=159378
EWMH web site is totally screwed up due to someone swapping out the wiki software apparently, so looking this up is a bit complicated... Here's some random mirror found on google: http://library.n0i.net/linux-unix/standards/ex-hints/ The spec there says "_NET_WM_WINDOW_TYPE_UTILITY indicates a small persistent utility window, such as a palette or toolbox. It is distinct from type TOOLBAR because it does not correspond to a toolbar torn off from the main application. It's distinct from type DIALOG because it isn't a transient dialog, the user will probably keep it open while they're working. Windows of this type may set the WM_TRANSIENT_FOR hint indicating the main application window." Whatever the latest spec says, I don't consider the spec gospel; I don't think we've ever had an app that used utility windows effectively, and until we do I don't think we can say we know exactly what their behavior is or should be. The basic idea of minimizing them if all normal windows are minimized seems plausible to me, since I don't know why you'd want them to not be minimized in that case. Also, on Mac the equivalent of a utility window would NOT be transient for the document window, the point is that the utility windows are shared among all document windows. The patch has a couple of things I'm wondering about, e.g. why is stack_position relevant, and it looks like we could be a little less aggressive about queuing the calc_showing for efficiency.
The GIMP uses at least one utility window, the toolbox. Many users (and the default set-up) have a second window including layers, channels, paths, paint-brushes and so on. These are exactly as you describe utility windows above, and I think it's reasonable that Metacity treats them in a way which makes sense for the GIMP. Perhaps you could say in what way The GIMP doesn't effectively use utility windows? Cheers, Dave.
*** Bug 159378 has been marked as a duplicate of this bug. ***
> The patch has a couple of things I'm wondering about, > e.g. why is stack_position relevant I don't know, I mostly copied the looping code from calculate_constraints() (or something) from stack.c. If you think stack_position shouldn't be checked, then that can be removed. > Perhaps you could say in what way The GIMP doesn't effectively > use utility windows? 1. Open Gimp. 2. Minimize Gimp. 3. Behold the dock (which has the utility window hint)! It's still there. It's not minimized along with Gimp. It just sits there, being totally useless and wasting screen space, and there's no way to get rid of it other than closing Gimp.
Hongli: Apologies for the confusion, I was asking that question to Havoc (re: comment #7: "I don't think we've ever had an app that used utility windows effectively"). Dave.
Poking at GIMP 2.0 I just don't think we have the utility window thing quite right. For example, they probably should not be focused when you click on them, the document you're editing should keep focus. Unless you click on a text entry... (and there's where the complexity lives). Also, the toolbox is very strange; the actual tool buttons part you would expect to be in a utility window, and expect to be able to close/reshow it like other utility windows. But I would not expect the whole app to close when closing a utility window. Anyway, stuff like that just needs figuring out. I don't have any objection to Hongli's fix here since it seems useful, though the patch needs a little bit of cleaning up.
So, what needs to be done for this patch to get accepted?
I would suggest that instead of fiddling with utility windows (which doesn't make much sense since the GIMP toolbox is by definition not a utility window), metacity should introduce support for window groups. GIMP sets a common class name on all GIMP windows including the ones created by plug-ins. If metacity would offer a way to minimize/maximize a window group, that would probably be a lot more useful.
When the utility option is turned on, does it turn even the main Gimp toolbox into a utility window? Why not leave that one as NORMAL, and then set the other utility boxes as transient descendants of the main gimp window? This would give the users the ability to minimize everything by minimizing the main gimp toolbox.
The GIMP user has the options to enable the utility window hint on the toolbox and / or the dock windows separately.
Ping? What will happen to this patch?
I think comment #14 indicates that this should be reported as an enhancement for (and thus be fixed by) metacity.
My latest comment was: > I don't have any objection to Hongli's fix here since it seems useful, though > the patch needs a little bit of cleaning up. I don't think window groups make sense, as they will add yet another concept/confusion to the current window nav situation which is already too complicated. Though if someone defined "groups" more precisely in terms of what behavior is added and came up with a feature that just worked (vs. adding another way users can micromanage things manually) I could probably be sold on it.
So what needs to be cleaned up? What do I need to do?
The things I saw quickly were: > The patch has a couple of things I'm wondering about, e.g. why is stack_position > relevant, and it looks like we could be a little less aggressive about queuing > the calc_showing for efficiency. To be more specific I'd basically have to do the work myself, as the hard part is figuring out which approach will be correct and efficient, there isn't a lot of typing to do.
updating status per comments
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use metacity and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.