GNOME Bugzilla – Bug 680990
Improve automaximize logic or make it optional
Last modified: 2018-02-05 09:43:53 UTC
In this commit http://git.gnome.org/browse/mutter/commit/?id=f2f500836ef217bfbd7bbf5ad54c9248cbdb7925 referenced from bug #671677 the behavior of automaximizing "nearly maximized" windows was added. This means in the case that someone wants to save a large, but not maximized window, the window size is not saved and is instead open maximized. See https://bugzilla.redhat.com/show_bug.cgi?id=831030 for examples. Is it possible to improve the logic such that windows are only automaximized if they are *very* close to fullscreen? If not, making the automaximize be optional somehow would be great. Currently it causes me a lot of frustration having to resize browser windows each time I open the application.
Created attachment 223800 [details] [review] automaximize: Make it optional Make automaximize optional by adding a gsetting "auto-maximize" (defaults to true).
Review of attachment 223800 [details] [review]: The reporter here was asking first about whether we could improve the logic...a bit sad we aren't trying to do that (or did we decide no logic improvement is possible?) Anyways, one minor comment, otherwise looks fine. Note we're in a freeze now...so I think this will have to land post 3.6. ::: src/core/prefs.c @@ +2077,3 @@ +gboolean +meta_prefs_get_auto_maximize () Should be (void)
I'm happy with making automaximize optional as well. But if the logic can be improved, that would also be good. Thanks for the patch!
(In reply to comment #2) > Review of attachment 223800 [details] [review]: > > The reporter here was asking first about whether we could improve the logic...a > bit sad we aren't trying to do that (or did we decide no logic improvement is > possible?) Well the suggestion was to "that windows are only automaximized if they are *very* close to fullscreen" which would just change the meaning of "nearly maximized" and likely trigger other similar reports. Unfortunately I cannot think of a better heuristic so I decided to just allow users to turn it off for now. This does not mean that we cannot improve on it once someone comes up with a better heuristic. > Anyways, one minor comment, otherwise looks fine. Note we're in a freeze > now...so I think this will have to land post 3.6. > > ::: src/core/prefs.c > @@ +2077,3 @@ > > +gboolean > +meta_prefs_get_auto_maximize () > > Should be (void) OK.
A better heuristic for me is "X pixels from the monitor's edge on all sides"
(In reply to comment #5) > A better heuristic for me is "X pixels from the monitor's edge on all sides" Why is that better? And who/what decides on the value of X?
(In reply to comment #6) > (In reply to comment #5) > > A better heuristic for me is "X pixels from the monitor's edge on all sides" > > Why is that better? Just a plain area doesn't take aspect ratio into account. You could want to leave some space on either side, but leave it mostly vertically maximized. > And who/what decides on the value of X? Trial and error.
*** Bug 684549 has been marked as a duplicate of this bug. ***
I'd like the commit reverted because the reasoning in the commit Windows that start up in a size that is almost as big as the workarea create extra work for the user (resizing or maximizing) so save the user's time by detecting such windows and automaximize them. clearly does not apply to me [1] and I don't think it applies in general, either (I haven't done a survey of the general population of users). The reasoning in the commit is also wrong because the way it should work is that if I maximize the window for app XYZ and then close it, then the next time I start the app the OS (e.g. either app or WM) should remember that app XYZ's window was maximized. It could be that things don't work the way I describe in the above paragraph but the way to fix it, _is_ not a hack like that commit - it's to fix the underlying problem. So, please revert. Thanks. [1] : Yes, I'm one of those weird people that actually don't like maximized windows and actually spend extra time making sure there's a nice amount of space from the window border to the workarea border. I know that I'm probably in a minority but I also know that I'm not the only one like this...
The problem with any simple "remembering state" design like that is the question of what happens whenever the world changes. For example, what happens if you start an app while you're on the train, then close the app, then go home, plug in in an external monitor, then start the app? Is it different when the original monitor is primary or not? This is basically the reason GNOME doesn't have traditional "session saving", at least I've never seen anyone attempt to describe a sane plan for how all the entries in the matrix get filled in. Anyways there are very clearly issues with the automaximize, but it's less clear to me that the right thing is to revert now. It does improve some use cases, and if we just reverted we'd break those. Dunno. We should bump this up as something to look at for 3.8.
The forced auto-maximise is a deal-breaker for me as far as GNOME shell is concerned. It's a huge annoyance and one that I upgraded to GNOME 3.6 from repositories in the hope was gone. I do not want my browser window (the only app it affects in my case) to be full screen (I have a 1280x1024 monitor) - if I did, I could set this with one click of the mouse. This is typical of the GNOME "developer knows best" mentality. I want this gone. It's my computer and I decide how big my windows are, not you. I used GNOME for years but this mis-feature spoils my enjoyment of the new version.
Hi guys, we're having clients who are using mutter as their WM for embedded applications/devices and Mutter's Automaximize feature is definitely getting in our way for technical reasons. We're really pushing hard to write code that will eventually go upstream, so I'd like to push that discussion forward to make it happen. I see there hasn't been activity in this thread for some time now... Jasper : I suggest we add a CLI switch (like the --no-force-fullscreen that was added to metacity a while back) and expose MAX_UNMAXIMIZE_WINDOW_AREA somehow so that we could just remove this behavior by setting it to 1.0. what do you think ? I could have a patch ready.
I think Adel's patch is acceptable. Is there someone who could consider pushing that upstream ? thanks.
Created attachment 228589 [details] [review] Patch to let plugins change the automaximize behavior Hi guys, we might be more inclined to add some API to let mutter plugins change the value of max_unmaximized_window_area. This still lets us disable the feature completely by setting the value to 1.0. Please consider the following patch, thanks. NOTE: This could be added alongside the already-proposed patch that disables automaximize through gsettings.
(In reply to comment #14) > Created an attachment (id=228589) [details] [review] > Patch to let plugins change the automaximize behavior > > Hi guys, > we might be more inclined to add some API to let mutter plugins change the > value of max_unmaximized_window_area. This still lets us disable the feature > completely by setting the value to 1.0. > > Please consider the following patch, thanks. > > NOTE: > This could be added alongside the already-proposed patch that disables > automaximize through gsettings. There's strong precedent for doing this sort of thing with gsettings + overrides rather than API.
*** Bug 690634 has been marked as a duplicate of this bug. ***
Comment on attachment 223800 [details] [review] automaximize: Make it optional Attachment 223800 [details] pushed as 2a2ac52 - automaximize: Make it optional
Review of attachment 228589 [details] [review]: Now that we have a gsettings key there is no need for an API (see Owen's comment).
Thanks for the setting -- nice Christmas gift :)
Review of attachment 223800 [details] [review]: ::: src/org.gnome.mutter.gschema.xml.in @@ +80,3 @@ + <_description> + If enabled, monitor nearly monitor sized windows automatically get + maximized when mapped. Is there a typo in this sentence ("monitor" twice) or is it just me having a hard time reading it? Also a translator comment explaining what "mapped" means would be very welcome.
Created attachment 236120 [details] [review] settings: Clarifiy auto_maximize language Use less technical terms and fix a typo.
Review of attachment 236120 [details] [review]: ::: src/org.gnome.mutter.gschema.xml.in @@ +89,3 @@ <_summary>Auto maximize nearly monitor sized windows</_summary> <_description> + If enabled, windows that open nearly monitor sized automatically get Still awkward wording, I'd say. "If enabled, new windows that are initially the size of the monitor automatically get maximized"
Created attachment 236125 [details] [review] settings: Clarifiy auto_maximize language Use less technical terms and fix a typo.
Huh(In reply to comment #20) > Review of attachment 223800 [details] [review]: > Is there a typo in this sentence ("monitor" twice) or is it just me having a > hard time reading it? Yeah, the first one doesn't make sense. Feel free to push a fix. > Also a translator comment explaining what "mapped" means would be very welcome. Sigh, does this show up in tweak tool? Personally I think that those strings should not show up anywhere but in dconf-editor (where technical terminology targeting developers is OK), but apparently the tweak tool authors disagree ...
Review of attachment 236125 [details] [review]: OK.
Comment on attachment 236125 [details] [review] settings: Clarifiy auto_maximize language Attachment 236125 [details] pushed as 24ff4b5 - settings: Clarifiy auto_maximize language
Not sure why this wasn't close. Closing.