GNOME Bugzilla – Bug 651075
maximize sovereign windows by default
Last modified: 2021-07-05 14:16:11 UTC
For most apps it makes sense to maximize the main window by default. This is especially true on smaller mobile devices. Really the only exception may be for huge ass workstation monitors. But not for all large displays. Your TV maximizes apps by default after all. Does it make sense to define an upper limit for maximization size? No sure.
A very close variation on this is part of bug 654046.
So, we've been discussing this for quite some time and I still don't have a good answer for how to handle "retina"/high-density displays. It is really hard to tell without understanding something about the viewing distance. Possible Cases: * Tablets: maximized * Laptops: maximized under 15"? * Netbooks: maximized * Desktop: monitors under 19"? * Projectors: maximized (since far away) * TVs: maximized
Why can't we look at it from a different angle. If the app's default size would take up 80% or more of the screen then maximize by default.
Seif, we do that now i believe. see bug 671677
In reference, I have raised this suggestion at Intel to members of the design team: "Possible Cases: * Tablets: maximized * Laptops: maximized under 15"? * Netbooks: maximized * Desktop: monitors under 19"? * Projectors: maximized (since far away) * TVs: maximized" And I think it is in the right direction
I've been repeatedly thinking about the physical size (and distance from the display) vs pixel size threshold. And I've come to a conclusion we are better off defining the threshold in px for now, just like it's being done on the mobile web now. The issue with not wanting a maximized window is similar to showing websites on a wide browser window/display. - text lines become too wide to comfortably continue reading on the next line - a fine balance of content is broken and replaced by vast amounts of whitespace - number of items in a grid shown goes past the ability to seek within it. While very similar, the problem of display density is mostly about things being too tiny. Even if you go maximized on an HD TV, you will not be getting a pleasant experience as you won't be able to read text, see thumbnails properly. You will need to address pixel density on a TV. I think a very simple rule of: - do not default to maximized on a screen wider than 1280px would be a good start. The rule would still be valid when we take density and viewing distance into consideration. On the web this is done through -webkit-min-device-pixel-ratio which defines a relative size of a pixel to make the pixel sizes make sense on a denser display such as the retina display on an iphone or the ipad3. The problem of scale would be a separate issue to the maximization though.
Taking back comment +7. After some more discussion, the pixel based threshold is still more problematic than one based on physical size. It would be wrong not to maximize on a 12" notebook if the width happens to be 1366px. What I have a problem with above should be addressed with a more flexible layout rather than cheating by going windowed.
TV are just monitors, but usually bigger than 20". Therefore the rule 'desktop over 19"' should be used → not maximized.
Not when they are 10 feet away and have the apparent size of a lot smaller than you laptop.
I think Jimmac nails it with the width-of-text-lines argument. If you maximize something and text lines become too wide to read comfortably, you've lost. (Interesting anecdote: when I installed "tree style tabs" on my Firefox and put the tabs on the left of the content area, web pages became much more readable - even though the window runs maximized, the content area is not overly wide.) What was the rule of thumb in typography? If you have text of N points in height, lines should be about 2N picas wide? So 12pt gets you lines of 24 picas, which is 4 inches.
https://meego.gitorious.org/meego-netbook-ux/mutter-meego/blobs/master/src/meego-netbook-constraints.c
If I understand correctly you are talking about default state (first launch of app)? Because subsequent launches should kind of remember the previous state. If my Firefox (or sth else) was maximized when I closed it, it means that probably I like it maximized and it should be maximized when I open it again. (Not just resized - some apps just resize, causing WTF moments. On Gnome 3.6, I don't remember which ones exactly.)
Just to add another use case, this is how I use one of my workspaces: .---------------------------------. |.--------------------------..---.| || Firefox || G || || || a || || || j || || || i || || || m || || || || || || || || || || |'--------------------------''---'| '---------------------------------' I would be very unhappy if GNOME automatically maximized my Firefox (due to some ">80% space" rule) on its every start. If it does it for the first time, no problem, I resize it. But then, it should remember the size. Another use case is Firefox occupying almost the whole screen except for a very slim space at the bottom of the screen, so that I see the last line of Terminal output beneath it. (Terminal is maximized, Firefox is almost maximized except for ~20 pixels at the bottom).
*** Bug 791683 has been marked as a duplicate of this bug. ***
Decisions shouldn’t be made due to resolution, but rather due to absolute monitor size and (fractional) scaling factor (maybe combined with pixel density) for getting a reasonable value of the actual “UI size”. This gives you more information about how big the UI is, how much space is needed for proper window size and how much space is left unused. A huge TV screen usually needs like 150 % scaling, so you won’t see as much as on a 15 inch monitor, despite it’s way smaller size.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.