[AppStream] Why are kudos not defined in the spec

[Matthias Klumpp]

2016-12-07 20:15 GMT+01:00 Richard Hughes <hughsient at gmail.com>:
> On 7 December 2016 at 19:11, Matthias Clasen <matthias.clasen at gmail.com> wrote:
>> I was trying to follow your howto for adding appdata to a new
>> application, and I couldn't find any definition of allowed values for
>> kudos - shouldn't this be in the appstream spec ?
>
> I've forwarded this on to the list; ximion I know you were hesitant to
> standardize these but I think we have enough apps doing this in the
> wild to standardize some allowed values.

I still am very hesitant to add anything like this, and have also
discussed this with several other software center app providers - so
far, GNOME Software is the only SC actually using this.

> Fwiw, these are the defines I've allowed in appstream-glib, but I'm
> open for ideas or additions. Some of the other kudos we show in GNOME
> Software we detect at runtime rather than encoded in the AppData
> files.
>
> /**
>  * AsKudoKind:
>  * @AS_KUDO_KIND_UNKNOWN: Type invalid or not known
>  * @AS_KUDO_KIND_SEARCH_PROVIDER: Installs a search provider

What is "a search provider"? Allowing GNOME specific stuff in there is
a very difficult thing to do, and also, why should an app providing
anything like that be rated better? And does the user even care? I'd
consider this an implementation detail.

>  * @AS_KUDO_KIND_USER_DOCS: Installs user documentation

This is useful to know, I think, but can and should we trust app
authors on just saying "yes"?

>  * @AS_KUDO_KIND_APP_MENU: Uses the GNOME application menu

Why does this matter? Also, GNOME specific...

>  * @AS_KUDO_KIND_MODERN_TOOLKIT: Uses a modern toolkit like GTK3 or QT5

Why do users care, as long as the app is working? I really think this
is something for the distribution's QA tracker and information for
developers. This will become even more difficult with Flatpak bundles,
which can ship anything. Also, what exactly is a "modern toolkit"? Is
GTK+3 old now, since GTK+4 exists?

>  * @AS_KUDO_KIND_NOTIFICATIONS: Registers notifications with KDE or GNOME

Same as with the search provider...

>  * @AS_KUDO_KIND_HIGH_CONTRAST: Installs a high contrast icon

Potentially be useful, do determine the accesibility status of an app,
but we could auto-detect this.

>  * @AS_KUDO_KIND_HI_DPI_ICON: Installs a high DPI icon

Again, something I would consider to be much better suited for a
distro QA tool or some QA done upstream, where the projects can
actually do something about it. The user just wants stuff to work, and
to have this just for sorting apps seems to be an overkill and
arbitrary.

> [..]

In general, I don't see yet how this information (except for "has it
documentation?" and "is its accessibility good?") will be something
users care about and want to know about prior to installing an app.
Additionally, I don't trust upstream projects at all to set this
information correctly and keep it up-to-date, especially not if it
makes their app show up higher in listings and have it earn some cool
badge. You might argue that this has never happened and that distros
can detect misuse of this, but I am thinking about large software
stores here and a mechanism where there is no independent developer
reviewing stuff and we can't check everything for correctness. If the
feature breaks in such a scenario, I don't consider it to be a good
idea for inclusion into the spec.

I dislike outright rejecting things, and I can see value in some of
the kudos stuff, but I'm afraid we will need some more discussion and
work something out which convinces me somehow that having this is a
good idea.

Cheers,
    Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/