GNOME Bugzilla – Bug 320673
allow me to maximize/minimize all windows
Last modified: 2020-11-06 20:08:37 UTC
Currently there exist some window types where maximizing or minimizing is not allowed. The menu entry is greyed out and the buttons aren't displayed, even though I want to perform this action. Examples are: - The filechooser in open mode. Maximizing is a good way to find a file when looking in a directory with many files. Instead I have to resize the window to the top left and bottom right end of the screen manually. - The "desktop background preferences" capplet. Minimizing is an easy way to get a feel for a newly selected image. Instead I have to either add a new workspace or close and later restart the capplet. I can understand that for dialogs minimize and maximize are normally unwanted features and therefore the obvious buttons are disabled, but I'd expect to at least be able to maximize/minimize a window and would expect the menu entries to never be greyed out.
I agree. GNOME/GTK file dialogs are extremely annoying. They are very polished, very responsive, in other words almost perfect... but... but.. BUT they only take up a small portion of the screen. I have a dual 1600x1200 setup, why should I struggle with scrolling in a tiny window, when a full-screen dialog can help me find my files much faster? The double manual resizing is unnerving to me. Especially when I have to open a bunch of files in the same crowded directory. I have no knives at my desk, or I'd stab myself in the leg. I can't see the problem with enabling the 'maximize' button. It doesn't make sense for an alert or confirmation window, but when there is content that adapts to the window size, such as in the case of 'Open file', then it makes a whole lot of sense. Does this belong in Metacity? IMHO this is a problem in whatever helper library is implementing the GNOME/GTK Open dialog. Non-Metacity users that try to run a GTK/GNOME program do not deserve such punishment. Same for the desktop background capplet.
(In reply to comment #1) > Does this belong in Metacity? IMHO this is a problem in whatever helper library > is implementing the GNOME/GTK Open dialog. Non-Metacity users that try to run a > GTK/GNOME program do not deserve such punishment. Same for the desktop > background capplet. I use Fluxbox, don't use the GNOME environment, and Gnumeric (1.7.14 now, the bug was in 1.7.13 too) does not allow me to maximize the window... The maximize button doesn't even show up. That is very annoying. Why can't GTK be sufficient for me to use that button?!??!
nutello, daniel: The window manager draws the frame around the windows with the minimize/maximize buttons, and is the one that decides whether a window gets such buttons. It does use hints from the application, but these apps aren't hinting "please don't allow me to be maximized/minimized", rather just things like "I'm a dialog". Now, the default size is definitely up to the application, so if you want to file a bug about file dialogs being too small by default then that could be filed against gtk+. But that's a different bug. If fluxbox also decides to not show the maximize button for certain windows, then you can file a bug against fluxbox, but trying to move this bug to gtk will get you nowhere because gtk+ can't fix whether the maximize buttons are shown or not. In short: yes, this bug belongs filed against metacity. There are other issues you could file against gtk+ (default size of file dialogs), or against other window managers (if e.g. fluxbox doesn't show the maximize/minimize buttons either and you think it should).
Thanks heaps, Elijah! You were right, the new stable Fluxbox (1.0.0) does display the maximize button correctly for Gnumeric.
The general idea of a dialog is that it's only supposed to be open for a short time. That's why they aren't cluttered up with window operations - you're supposed to read the dialog, maybe click a couple of controls, and press one of the buttons to close it. If a window isn't like that, it probably should not have type DIALOG. While I can see that there's a small convenience to having maximize and minimize for these two particular dialogs, they are not typical, and the problems here aren't large. You could also resize by dragging the corner, or move the dialog off the right side of the screen, or close it, or switch to an empty workspace. If truly appropriate, the apps themselves could also set the window type to NORMAL rather than DIALOG. Or the apps could have some other solution; e.g. the background dialog could offer a preview mode either inside the dialog or some setup where the dialog hides itself or shrinks into a button in the corner. Or e.g. the file dialog could be larger by default. In short, IMO these problems are best solved by changing the apps, not by changing the behavior of dialogs in general.
I am not sure I agree there. I see two reasons for fixing it in Metacity: 1) convenience It is just way simpler to have a fix in Metacity than changing all current apps that show this behavior plus all future apps that have the same issue. (The most common problem I have this issue with: Dialogs that show tree views, like for example the sensors applet properties.) 2) user override I have learnt that the if in doubt between computer and user, the user is always correct. And since there is no technical problem with providing maximize functionality, I don't see why Metacity should deliberately hide functionality from me. What I can see is the argument that simple windows shouldn't have a needless amount of buttons to confuse people with, when those buttons are not needed in most cases. But I'd advocate to still show the maximize/minimize entries in the window menu, so people are still able to override.
The "hidden easter egg" ability to maximize is just gross IMO, makes things inconsistent where you can maximize everywhere except via window buttons. First thing we'd get is bugs about "why are the menu and task list inconsistent with the window controls," and those bugs would seem legitimate to me. The reason for "hiding functionality" is that displaying all possible anything anyone might ever want to do would be hideous and awful. So I don't think that guideline works as a way to draw a line between features to have and not have; it doesn't, by itself, exclude enough stuff or tell you _what_ to include, it only defines a huge universe of things the software _could_ include. Said huge universe is much, much larger than what metacity in fact does include. So whether the "user is always correct" guideline is correct or not, it still leaves us with the need to dramatically subset the set of things it would lead us to include. We can do the subset via editorial judgment or additional guidelines. In any case, "include anything that anyone ever wants" is certainly not the design principle behind any of metacity, though it appears to be the one behind a number of other WMs, so I think it's nicer to preserve user choice by having metacity be different from other WMs. Some users want to choose a WM that is pre-designed to handle the common, default cases in a smooth and aesthetic way, without a lot of distracting "well, maybe occasionally someone wants to do this..." kind of tangents. Messing up metacity would remove this choice since no other WM seems to have the will to do this. If nothing else I'd say the presumption is heavily against this change just because it's been the way it is for many years with no real complaints.
Hello Havoc, I agree with most of what you said, but I have one question: If a dialog is resizable, why can't it be maximised? This is inconsistent behaviour. Nobody is asking for some fancy new feature (without looking at the code, my gut feeling is that to address this you'd have no net gain of code or even be able to remove some lines). I don't think anyone is asking to enable maximising for all dialogs, either. It's only about removing a special case. If we hypothetically had started from the general principle that anything that is resizable can also be maximised, what would be the purpose or reason to add this special, artificial exception? You say that dialogs are meant to be opened for a short amount of time. Well, I find that the current behaviour makes them stay up even longer than necessary for me. Moving up to a dual 1200x1920 setup only made things worse. Rudi
(In reply to comment #7) > The "hidden easter egg" ability to maximize is just gross IMO, makes things > inconsistent where you can maximize everywhere except via window buttons. First > thing we'd get is bugs about "why are the menu and task list inconsistent with > the window controls," and those bugs would seem legitimate to me. > Besides the fact that the menu and task list are already inconsistent with the window buttons (there's no "always on top" window button etc), I agree that it's probably not a very nice solution. I'm fine with any solution, as long as it maximizes my window. Could as well be an "always-maximize" button in the gconf button layout. > If nothing else I'd say the presumption is heavily against this change just > because it's been the way it is for many years with no real complaints. > I don't agree on the "entirely no complaints" point. I remember lots of discussions about all sorts of windows and what type they should appear as in the past years. Nonetheless, Gnome has managed to make this pretty much work with Metacity's behavior.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue 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 fixed.