New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
display_length size constants don't reflect actual screens #335
Comments
FWIW this is why I always thought the named values were a bad idea. At the end of the day what matters are the actual logical pixel values apps can scale to. This just obscures that, making it easier to get it wrong. Even if we e.g. change the |
On a practical level, what are our options here? Can we deprecate/remove the named values altogether? If so, that'd be the best path forward IMO. If that's not an option, can we add/remove/change the meaning of the various values? If so, to what degree? |
We can't remove the named values, but we can always change what they mean, as that is exactly their intended purpose (for apps which are fully adaptive and really don't care all that much about explicit sizes, because specifying an absolute size means the app will not show up on a phone that is just a bit too small or a bit too large). |
That doesn't exist, sorry. Apps are optimized for a very specific minimum width. If you give them smaller width, they will break. Or rather, they won't fit into the screen. |
This markup mimics prior art from Android, which also allows both: https://developer.android.com/guide/topics/manifest/supports-screens-element (Android also scales apps up if they don't fit into large screens, which is of course not desirable for most). |
Except a few releases later they found out that this system doesn't work, because
I think they should be deprecated to be completely honest. Or rather that they shouldn't have existed in the first place but that ship has sailed. |
Yeah, after giving this some more thought, I think deprecating the text representations for now is the most straightforward, simplest way that won't cause too many issues in the long run (as long as app developers update their metadata, which I assume they do). |
Just my 2 cents: I would like to have a Way to say that a App needs a screen class without using a fixed size. e.g. you have a IDE that have sidebars, terminal, editor etc. on the screen. It would be good to just say, this App recommend large screen. On the other Hand, it's good to say that a App which has not many Things that are on the Screeen at the same time, work on every Laptop/PC screen size (not on mobile) without figuring out the exact resolution. |
There are a few problems here:
small
size is meant to be used on phones, yet all the available phones have360px
and so fall intoxsmall
xsmall
doesn't constrain the minimum screen sizesmall
means the app cannot run on it,xsmall
means the app can run on even smaller screens which is not really the casemedium
is means for laptops whilelarge
for bigger computer monitors - the most common laptop resolutions are 1366x768 (mostly low-end), 1920x1080, and there's also 2160x1440@2 which means 1280x720. So laptop sizes can be 720px, 1080px - the former falls intosmall
, the latter falls intolarge
- so themedium
description is misleadingxlarge
corresponds to the largest screen side. 4K screens are 3840x2160 - the value there is 2160px so they are still considered large, soxlarge
only corresponds to 8K screens.CC @bertob
The text was updated successfully, but these errors were encountered: