GNOME Bugzilla – Bug 671677
unmaximizes to nearly maximized size
Last modified: 2012-03-22 17:40:12 UTC
It seems that when we unmaximize a window we try to restore it to the previously used size. This is problematic in certain cases where the restored size is very close to the workarea size (previous maximized size). This can occur when windows move between physical displays or when explicitly sized by the user. Basically we don't really want to create windows that are almost maximized in size but not actually maximized. This creates work for the user and makes it very difficult to use and resize manually. Related to this is 3) in bug 654046 or bug 651075. Concretely, I think that when we unmaximize a window we should use something like the following logic: Set the newly unmaximized window size to the previously used size or 80% of the size of the current workarea (attempting to retain natural aspect ratio if possible), whichever is smaller.
Created attachment 209503 [details] [review] Don't unmaximize to nearly maximized size Basically we don't really want to create windows that are almost maximized in size but not actually maximized. This creates work for the user and makes it very difficult to use and resize manually. So set the newly unmaximized window size to the previously used size or 80% of the size of the current workarea (attempting to retain natural aspect ratio if possible), whichever is smaller.
Created attachment 209504 [details] [review] Don't unmaximize to nearly maximized size Basically we don't really want to create windows that are almost maximized in size but not actually maximized. This creates work for the user and makes it very difficult to use and resize manually. So set the newly unmaximized window size to the previously used size or 80% of the size of the current workarea (attempting to retain natural aspect ratio if possible), whichever is smaller. --- Check the min size.
I must say that's really great improvement! Do you think it would also be possible to trigger a maximization when applications set their window sizes to something close to the screen size? For example, Evince can get a default window size from a PDF document to something that's almost as large as the screen. Instead of relying on applications to be overly smart, the WM could take the decision for them.
That's one thing that Nick proposed in item 3) of bug 654046 . It probably does make sense I think.
Review of attachment 209504 [details] [review]: The code looks correct, but I wonder if it's in the right place - if a window maps a window almost at screen size, you have to maximize/unmaximize to get it restricted to a "reasonable" size. Maybe adding a constraint (or modifying an existing one) is a better alternative? ::: src/core/window.c @@ +3800,3 @@ + */ + if (unmaximize_horizontally && unmaximize_vertically && + desired_rect->width * desired_rect->height > work_area.width * work_area.height * 0.8) should probably use a constant here (MAX_UNMAXIMIZED_WINDOW_AREA?)
Created attachment 209528 [details] [review] Don't unmaximize to nearly maximized size Basically we don't really want to create windows that are almost maximized in size but not actually maximized. This creates work for the user and makes it very difficult to use and resize manually. So set the newly unmaximized window size to the previously used size or 80% of the size of the current workarea (attempting to retain natural aspect ratio if possible), whichever is smaller. --- Implementation using a constraint.
Review of attachment 209528 [details] [review]: Looks good to me - unless we want ·"large" windows automaximized on map instead, feel free to push. ::: src/core/constraints.c @@ +915,3 @@ + { + float aspect = (float)info->current.height / (float)info->current.width; + info->current.width = MAX (work_area.width * 0.8, window->size_hints.min_width); I still think a #define is better than hardcoding 0.8 twice.
Created attachment 209856 [details] [review] Don't unmaximize to nearly maximized size Basically we don't really want to create windows that are almost maximized in size but not actually maximized. This creates work for the user and makes it very difficult to use and resize manually. So set the newly unmaximized window size to the previously used size or 80% of the size of the current workarea (attempting to retain natural aspect ratio if possible), whichever is smaller. --- Use a constant instead of a hardcoded value.
Created attachment 209857 [details] [review] window: Automaximize large windows on map Automaximize windows that cover >= 95% of the work area on map.
Created attachment 209858 [details] [review] window: Automaximize large windows on map Automaximize windows that cover >= 95% of the work area on map.
Created attachment 209859 [details] [review] Don't unmaximize to nearly maximized size Basically we don't really want to create windows that are almost maximized in size but not actually maximized. This creates work for the user and makes it very difficult to use and resize manually. So set the newly unmaximized window size to the previously used size or 80% of the size of the current workarea (attempting to retain natural aspect ratio if possible), whichever is smaller. --- Reattach ...
Created attachment 209864 [details] [review] Don't unmaximize to nearly maximized size Basically we don't really want to create windows that are almost maximized in size but not actually maximized. This creates work for the user and makes it very difficult to use and resize manually. So set the newly unmaximized window size to the previously used size or 80% of the size of the current workarea (attempting to retain natural aspect ratio if possible), whichever is smaller.
Created attachment 209865 [details] [review] window: Automaximize large windows on map Automaximize windows that cover > 80% of the work area on map.
Created attachment 209866 [details] [review] window: Automaximize large windows on map window: Automaximize large windows on map Automaximize windows that cover > 80% of the work area on map. https://bugzilla.gnome.org/show_bug.cgi?id=671677 (git-bz strikes...)
Comment on attachment 209866 [details] [review] window: Automaximize large windows on map or not ...
Review of attachment 209864 [details] [review]: ::: src/core/window-private.h @@ +64,3 @@ +/* Windows that unmaximize to a size bigger than that fraction of the workarea + * will be scaled down to that size (while maintaining aspect ratio) */ +#define MAX_UNMAXIMIZED_WINDOW_AREA .8 I don't think the define belongs in the header - it is private to window and not interesting to anything outside. ::: src/core/window.c @@ +3806,3 @@ + float aspect = (float)desired_rect->height / (float)desired_rect->width; + desired_rect->width = MAX (work_area.width * MAX_UNMAXIMIZED_WINDOW_AREA, window->size_hints.min_width); + desired_rect->height = MAX (desired_rect->width * aspect, window->size_hints.min_height); I think we should try to get as close to MAX_UNMAXIMIZED_WINDOW_AREA as possible - here we are way smaller. It is very obvious for the extreme case of desired_rect having the same size as work_area, in which case we get: if (w * h > w * h * SOME_FACTOR) { new_w = w * SOME_FACTOR; new_h = new_w * (h / w) = w * SOME_FACTOR * (h / w) = h * SOME_FACTOR; } So we end up with the window covering an area of w * h * SOME_FACTOR * SOME_FACTOR - TL;DR: I really think we want sqrt(SOME_FACTOR) here :)
Review of attachment 209865 [details] [review]: Code looks good, but the commit message is pretty poor - the body is just repeating what the subject says, would be good to quickly mention the motivation behind the change there :) ::: src/core/window-private.h @@ +67,3 @@ +/* Windows larger then this fraction of the work area get automaximized on map */ +#define AUTO_MAXIMIZE_MAP_THRESHOLD .8 Again, not sure this belongs in the header. Also, I don't think it makes sense to use different values here, so maybe we shouldn't use separate defines either?
Created attachment 209879 [details] [review] Don't unmaximize to nearly maximized size Basically we don't really want to create windows that are almost maximized in size but not actually maximized. This creates work for the user and makes it very difficult to use and resize manually. So set the newly unmaximized window size to the previously used size or 80% of the size of the current workarea (attempting to retain natural aspect ratio if possible), whichever is smaller. --- *) Move constant *) Use sqrt
Created attachment 209880 [details] [review] Automaximize large windows on map 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 windowsn and automaxmize them. --- *) Share constant *) Improve commit message
Review of attachment 209879 [details] [review]: LGTM
Review of attachment 209880 [details] [review]: Last line of the commit message: "windowsn" "automaxmize" - good to go with those fixed.
Attachment 209879 [details] pushed as c39998e - Don't unmaximize to nearly maximized size Attachment 209880 [details] pushed as f2f5008 - Automaximize large windows on map
Thanks for that! Now, a suggestion: couldn't this also be done when un-maximizing a half-maximized (vertically) window ? In this case, the vertical size of the window should be forced to about 80% of the last-saved window size if needed. The horizontal size, however, could be set to something like 60% of the horizontal size of the screen, at least, so that it becomes obvious that the window is not half-maximized anymore. This is particularily needed because of bug #315647.