Extend recommendation expressiveness spec

[aleixpol]

Include 2 extra requirement types: screen size and input type.
Make it possible to specify recommendation by whether it is just
supported.

This is a proof of concept, of course. Feedback very welcome.

[aleixpol]

ping?

[hughsie]

I guess I'm not sure of the bigger picture; is a <input>touch</input> application going to be hidden on a non-touch device, or promoted more but still available on a touch-capable device?

[aleixpol]

I guess I'm not sure of the bigger picture; is a touch application going to be hidden on a non-touch device, or promoted more but still available on a touch-capable device?

That's why we need either requires, recommends or supports. If we are talking about supports then it should be listed, if it requires touch, then if there is no touch it shouldn't be displayed.

Does that make sense?

[hughsie]

That's why we need either requires, recommends or supports.

Agreed, although supported might be clearer than supports

[aleixpol]

We already had <recommends><input>touch</input></recommends>, given this, I'd say <supports><input>touch</input></supports> is what makes most sense.

[ximion]

@aleixpol @hughsie Do we really need another toplevel tag for this?
We could have

<recommends>
  <input>touch</input>
  <input>mouse</input>
</recommends>

just fine, couldn't we? The only issue here is that a recommends tag chains its items with an implicit AND, which is wrong for input methods (you rarely use multiple of those).
If we end up having supports it would have to be named supports (not supported) to be in line with the existing recommends, requires, suggests, extends and provides tags.

Also, this request touches parts of another feature request filed as #55

Also, sorry for not replying, my schedule is crazy at time.

[aleixpol]

The only issue here is that a recommends tag chains its items with an implicit AND, which is wrong for input methods (you rarely use multiple of those).

Maybe turning <recommends> into an or could fit the bill. Or maybe the difference between <recommends> and <supports> could be the or logic.

Also, this request touches parts of another feature request filed as #55

I guess #55 don't necessarily need to be libinput types?

[ximion]

Maybe turning into an or could fit the bill.

That would be a breaking change AND inconsistent behavior with the other tags, so that's a definite no-go...

I guess #55 don't necessarily need to be libinput types?

Jup, so maybe that needs some slightly different solution. There is some great overlap here though.

The more I think about this issue, the better I find adding a supports toplevel tag - as insane as having so much expressiveness (supports, recommends, requires, extends, suggests) is, it does serve a useful purpose, and supports is distinct in meaning from recommends in that the former means a component work with other components/features, but doesn't need them to be present, while the latter (recommends) indicates a clear preference.
So, recommending touch input is clearly different from supporting it, and recommending a higher resolution screen is different from supporting it.

So, at the moment I am leaning towards just accepting supports. Implementation-wise, it would just be another enum entry in AsRelation.

[ximion]

In order to move this forward and address the most common cases, I am currently looking at the following:

• Add a supports tag in addition to the existig relations tags

• Add a chassis relation item, with allowed values:

  • workstation
  • tablet
  • handset
  • watch
  • embedded

  This will allow software centers to hide apps based on the form factor of the current machine. See the systemd machine-info chassis types for reference: https://www.freedesktop.org/software/systemd/man/machine-info.html (I folded desktop, laptop, convertible and server into "workstation" here, I still need to think about whether that is a good plan)

• Defer the input and screen relation item discussion to later, to keep this simple for now. Those tags are actually quite hard to test for application authors (esp. the screen one). We can add them at a later time if we see that they are necessary.

What do you think?

[cassidyjames]

I folded desktop, laptop, convertible and server into "workstation" here, I still need to think about whether that is a good plan

Something we learned in elementary OS when designing power settings was that distinguishing based on a "group" of hardware gets increasingly arbitrary and confusing as device form factors overlap. We've found it almost always makes more sense to just define the actual hardware we require or are looking for—so in some cases it's an embedded display or attached battery, other times it's a touchscreen, sometimes it's an accelerometer. My concern with the proposed chassis groupings is: what distinguishes a "handset" from a "tablet"? What separates a "tablet" from a "convertable"? These distinctions always fall back to some specific hardware differentiation, so I don't know that creating these buckets makes sense. Especially if I have a small phone-sized tablet with a physical keyboard.

[aleixpol]

Doint it around "chasis" won't solve #55 either. It's just turning into information we don't know about.
In the end, the software centers can decide it's a watch because the screen is 3cm.

Maybe using libinput as a reference was wrong because it's a very specific kind of input (was thinking voice) but libappstream can't be guessing, as cassidy puts it.

supports is what we have already on the patch.

[ximion]

So, I started that discussion again on the AppStream ML: https://lists.freedesktop.org/archives/appstream/2020-February/000337.html - hopefully we can get some kind of solution for this.

[ximion]

This is resolved via #265 for input controls. Screen sizes still need a bit more work and research.
If you have insights or feedback to give, please participate at https://lists.freedesktop.org/archives/appstream/2020-February/000337.html
Thanks to anyone involved with this PR, it was very helpful to get this ball rolling (even if it rolled reeeeeealy slowly, which was my fault).