[AppStream] Information about "mobile-readiness" in AppStream

[Matthias Klumpp]

Am Mi., 5. Feb. 2020 um 19:18 Uhr schrieb Aleix Pol <aleixpol at kde.org>:
>
> On Wed, Feb 5, 2020 at 5:57 PM Matthias Klumpp <matthias at tenstral.net> wrote:
>> [...]
>
> Hi Matthias,
> Thanks for bringing it up. We actually talked about it yesterday at
> the Plasma Mobile sprint, it's definitely something important for us
> as well.
>
> I'd say that using the input methods as a first iteration would work
> fine, adding screen limitations and others later on.

That would make things a bit easier, to not define everything at once,
but we do need to keep this in view at least.

> Regarding the supports, I did it so we'd be able to sort rather than
> out right filter on such lists, at least on some cases. We don't want
> to make the queries so restrictive that we end up with 3 apps being
> listed... Differences between supports and recommends can be too small
> though.

Yeah, I am more and more thinking that recommends may actually be
enough here, and that we don't actually need to define a whole new
relation type.

> Another question is what we are going to do with everything lacking
> such metadata. Should we assume that everything requires a keyboard
> and mouse unless the application introduces the restrictions?

Yes, that would be the most backwards-compatible way.

> Or assume that they don't support, require and recommend anything?

That would ultimately mean the same thing, wouldn't it? At least as
far as filtering goes, otherwise you would currently filter out 100%
of all apps when looking for stuff that is easy to use with a mouse.

One idea I had in the past was to introduce a "gui-application"
component type that would ultimately replace the "desktop-application"
type but be the same thing. (lib)AppStream could use the different
strings for the same component-type to attribute a "works with
mouse/keyboard" to anything that uses the "desktop-application"
string, and expect from apps using "gui-application" to actually
define this in their metadata.
However, I am not super convinced of this and a plan like this is
pretty much 1.0 release material.

appstreamcli validate will certainly nudge people to add missing
metadata in case we decide that it should be explicitly defined by
application authors ;-)
(Personally, I think "assume works with keyboard/mouse if no input
recommendation defined" is a very reasonable thing to do)

That said, we still need to define how to define a supported input method.
First of all, I am against calling this "input method" in any form,
because we already have an AppStream component type of that name[1]
defining ibus input methods like for math or Asian glyphs. So I am
currently favouring "control", "input" or "input_control" as names.
Second, looking at Wikipedia[2], there are a ton of different devices
used to input stuff. Listing them all is unmanageable, so I would
rather group them together into classes of input devices, such as
"pointing devices" for everything that controls a cursor on screen, be
it a mouse, trackpad, etc.
Additionally, I would like to restrict the usecase of this to only
devices that actually *control* the actions of the program. For
example, a video recording application may receive video as an input,
and an attached camera is an input device for it, but it does not
control what the application does. It is mere data input. Same for an
audio recorder that records music. However, if a program would record
voice commands to be controlled by them, that would be an input device
that does control the application.

So, what about this preliminary list of controlling input methods:
 * pointing  (mouse, trackpad, ...)
 * keyboard
 * gamepad  (any game controller with wheels/buttons/joysticks)
 * touch  (control by touching a surface with fingers)
 * voice  (voice recogition/activation control)
 * vision  (control via computer vision, e.g. by detecting hand signs)

Especially when it comes to gaming controls, as [3] outlines, there is
much more stuff around to input data, but I do want to have a
manageable list of stuff in here. Potentially, allowing a "freeform"
input string makes sense though, in case we really want to filter out
devices that can be controlled by dancemats and guitars.

In AppStream, using these tags could look like this:
```
<recommends>
  <control>touch</control>
  <control>pointing</control>
  <control>keyboard</control>
  <control>gamepad</control>
</recommends>
```

Using this is "requires" would obviously mean an app isn't installable
on a device that doesn't have the selected input method, which is
probably not a thing developers would want to do in most cases.

Cheers,
    Matthias

[1]: https://www.freedesktop.org/software/appstream/docs/sect-Metadata-InputMethod.html
[2]: https://en.wikipedia.org/wiki/Input_device
[3]: https://github.com/ximion/appstream/issues/55

-- 
I welcome VSRE emails. See http://vsre.info/