WIP: Specify display_length requires/recommends item

[ximion]

This change adds specification text to allow applications to require a minimum display width and/or height in order to be installed or run with recommended settings.
This change would address #285

CC: @hughsie @Apol @hadess @Exalm

[ximion]

One alternative way of writing this, in case we do not care about both width/height that much, would be

<display_length side="shortest" unit="cm">10</display_length>

to only set constraints on the shortest/longest edge of a device's screen. This may be enough for most devices (shortest side being default if side isn't given as property) and would avoid having special wording for devices with screen rotation.

[agx]

My take away from the discussion so far was: logical pixel is must have. It's currently mostly interesting for small screen sizes but might also be useful for large screens to avoid lots of unused space.

Physical size + viewing distance would be important for e.g projectors and TVs but it's orthogonal to logical pixels so i'd not try to lump both into one but make them clearly separate things to make sure they don't get confused,

[bertob]

My current theory is that logical pixel size is the only thing we need/want from an app developer point of view.

I think we can assume that the system HiDPI scaling factor is such that the system is UI is a legible size. Thus, the OS has to take care of both physical size and viewing distance via scale factor, and there's no reason for app developers to care about these variables directly, or do anything different from the rest of the system.

As far as I can tell this holds across all device types (including outliers like TVs and watches) and I don't think any of them are special in this regard. There are of course other differentiating factors that are relevant for app developers (e.g. remote-only input for TVs, or touch-only for phones), but I don't think physical display size is among them.

I'd be happy to be proven wrong if someone has a counterexample, but so far I haven't seen any.

[agx]

As far as I can tell this holds across all device types (including outliers like TVs and watches) and I don't think any of them are special in this regard. There are of course other differentiating factors that are relevant for app developers (e.g. remote-only input for TVs, or touch-only for phones), but I don't think physical display size is among them.

Display size and distance+distance can matter if you want to know if e.g. the thumb can reach the whole screen and some other caes but i'm not trying to make a case for physical size here but the contrary.

[bertob]

if e.g. the thumb can reach the whole screen

That's a good point. I suppose it's an input rather than a display issue though, and what you're interested in isn't just the size of the display but also the size of the entire device (and perhaps even thickness)? A 5" display can be ok to use with one hand if there are no bezels, but if there's a 1cm bezel at the top and bottom it might not be anymore.

Perhaps for this a slighly more subjective "single-handed usability" metric that takes various factors into account might be better?

That said: If we had this, how would this information be used by app developers?

[dcz-purism]

I've been thinking along the same lines: reachability would be "purer" if it was its own mode of input. Two issues: would people actually bother declaring "my application is good with a thumb only" as opposed to just setting the screen size requirements? Also, it kind of forces the admission that granular choices are acceptable: "requires multitouch", "requires a scroll control", "can be used entirely with the left thumb on landscape", "can be used keyboard only", etc.

[ximion]

An important thing to not is that this information is not for applications, nor is it for application developers. It is information for tools like KDE Discover, GNOME Software, Cockpit, Flatpak, etc. provided by applications for filtering components and informing users as well as making automated decisions.

@bertob 's argument for logical pixels makes sense to me, even though this can be flipped around as well: You can expect the device to make the texts and UI elements readable for its logical pixel size, but you can also expect the same when you request a physical length in mm. I made the display's physical size the default mode, because it fits the purpose of limiting apps to formfactors better than a logical pixel size, which is configuration dependent. But I do not feel very strongly about that.

By going for logical pixels, as soon as you reduce your resolution, your screen becomes "small" for the software center and it will therefore reveal apps that are only designed for smaller screens. While if you increase the resolution on a tiny screen, desktop apps will show up because the screen is now "larger" (even though all UI elements are tiny now). I think that's not a very likely scenario, in the majority of cases systems will be configured well, but the very fact that by using logical pixels you will check for a device+configuration rather than just checking for physical device limits is something I do not like that much.
This property is ideally supposed to check for device properties and not for configuration.

One important thing to remember is that display_size is only part of the puzzle. Applications can already make recommendations on which input methods they support for more than a year, so if your app recommends only a large TV screen it's very unlikely that it will also recommend touch input (but I think that is a fringe case anyway).

@agx I wouldn't throw viewing distance into the mix unless some actual usecases come up for that. Currently I think if the screen is large enough, a larger viewing distance can be assumed and that's "good enough". This property in AppStream is not supposed to give any precise measurement like a phone shell would do, neither to provide any information relevant for drawing the app's UI. Its purpose is solely to allow filtering apps by screen sizes they are designed for, so Libre Office will require a Tablet-Laptop-sized screen, phone apps will require a small screen and adaptive apps will not use this property at all and just run on any screen size (and they will only set the control tag to advertise touch input capabilities in addition to keyboard & mouse).

[agx]

@ximion i only brought up viewing distance since for e.g. projectors the physical display-size is ill defined - but as i said: i wouldn't even worry about that for now since from what i've read here so far the only things that software centers (and also shells) would care about atm is logical pixels (and maybe input types).

[bertob]

I made the display's physical size the default mode, because it fits the purpose of limiting apps to formfactors better than a logical pixel size, which is configuration dependent. But I do not feel very strongly about that.

The problem is that it doesn't guarantee anything concrete with regard to whether an app will actually work on your display in the current configuration, which is the entire point of filtering apps in app stores, making it kind of useless for our purposes. The exact number of logical pixels an app scales down to is easily measured, but I really don't think we want app developers physically measuring their phones and putting that in metadata...

If you increase/decrease the resolution/scale factor on a device that impacts which apps fit the screen, so it makes sense that this changes what's available in Software. I get your point about device properties vs. configuration, but in practice the scale factor is basically part of device properties here, because there's generally only one good option (e.g. 2x on the Librem 5) and the device is unusable if you misconfigure it.

The idea with adaptive design is precisely that it doesn't matter whether you're running an app on a phone, desktop, TV, etc. as long as it fits the screen and supports the relevant input methods. As far as I can tell bringing physical sizes into this doesn't give us anything for displays (though it might be relevant for input).

[ximion]

The problem is that it doesn't guarantee anything concrete with regard to whether an app will actually work on your display in the current configuration, which is the entire point of filtering apps in app stores [...]

That depends on what you actually really want to test for - the device, or the configuration.

The idea with adaptive design is precisely that it doesn't matter whether you're running an app on a phone, desktop, TV, etc. as long as it fits the screen and supports the relevant input methods. As far as I can tell bringing physical sizes into this doesn't give us anything for displays (though it might be relevant for input).

Yes - fortunately the input part is already handled by a different property, so we don't need to worry about it :-)

[ximion]

Here is a new revision with (most?) feedback incorporated. I originally wanted to defer adding the mm unit type, but given that both Qt and GTK+ have easy API for that and it's simple to implement and test, we can just add it now.
The two with/height tags are also now just one, checking for the shortest display side by default.

[bertob]

I'm still not sure what the potential use cases for millimeters are, so unless there's something else I'm missing I'd stick to having logical pixels only.

[ximion]

It's mimicking the existing Qt and GTK+ APIs as well as future-proofing the design (some adaptive apps may care more about the form factor than the drawing distance).

[Exalm]

Which GTK APIs? GdkMonitor etc? Not sure what an app would use them for tbh, other than misusing them like in https://github.com/stdmedoth/simplenav/blob/dcfe229abcb1a6e31321407ae8855b8ad4c74fc7/src/init.c#L18-L20 (set_size_request() works with logical pixels)

[ximion]

If there's no further comment, I would move forward to implementing the current draft, only removing the side property for now (as we can always add that if we need it, while any other changes are harder to make).
Maybe some new issues will come up while implementing this, but if things go smoothly this feature may be in the (hopefully very soon to be released) AppStream 0.12.12 release.

[ximion]

I've reduced the scope of the initial display_length tag a bit (only a side property allowed, only px as unit type for now) and added some more clarification text to the specification.
Also, I implemented the current specification draft. I still don't like it 100%, but I also have no ideas how to do this differently and achieve something that's better and still versatile enough.
I would merge this code soon to be part of the upcoming AppStream 0.12.12 release (maybe released next week).

Please note that the display_length spec is relies very heavily on the assumption that it is the shortest screen edge that apps care most about. It also, by doing that, kind of implicitly assumes that screens can be rotated, which is a bit mobile-centric. But since anything that isn't running on small or very large devices will have a <display_length>medium</display_length> recommendation anyway or not use this tag at all, it's probably fine.