Adopting AppData in KDE?

[Matthias Klumpp]

2013/11/5 Todd <toddrjen at gmail.com>:
> [...]
> Looking at the spec, I have a few suggestions:
(I assume you mean the AppStream spec)
> For <project_group/>, I think it would be good to allow arbitrary groups
> rather than limiting it to only a few recognized groups.  This is another
> gatekeeper issue: no project our group would have the authority to say which
> group is and is not acceptable.
project_group allows arbitrary values already, the specs just say
"known values include..." which is in no way a recommendation. And I
am not planning to change that ;-)

> I also think sleeping multiple groups and/or sub-groups.  KDE at least had
> sub-groups like KDE edu, KDE multimedia, and calligra.  I think it would be
> good for apps to be able to identify themselves as belonging to one of these
> groups.  I could also see an application providing, say, gnome/KDE
> integration that could benefit from belonging to both groups.
I think this would be overly confusing for users. Just say "KDE-Edu"
or "KDE-Multimedia" would make some sense... But in all cases, the
applications are part of the KDE umbrella project. Mozilla also has a
"Mozilla Messaging" department, but it is still listed as "Mozilla".
I am not sure of what value adding subgroups would bring to the users...

> I think it would be good too either have a change log tag or a
> machine-parseable change log spec that would allow app stores to display the
> change log (that is something that bothers me about YaST, you can only view
> a change log after the app is installed).  It needs to be in a reasonably
> consistent format so the app store can extract the changes for the most
> recent version, the date of the last release, and the most recent version
> number.  The Android app store provides this information, for example.
This is already done via PackageKit for the connected package.
Including upstream information would require extra logic for parsing
version numbers of every distribution, and it would require additional
caches for chagelogs.
I like the idea, but having distributor's changelogs is nicer at time.
It also will be insanely difficult to get all app authors to write a
machine-readable changelog and change the changelogs they are writing
already.

> Regarding mimetypes, I recall there had been some concern over apps that get
> their mimetypes dynamically either at build-time or runtime from other apps
> or libraries.  Might this be a good opportunity to find a solution to this?
> As with the add-ons I mentioned previously, the app-store can either
> atomically download these plugins or allow the user to download them.  The
> details would be left up to the implementation I assume.
This is slready done, some implementations exist :-)

> It might be good to have an email address for the person or mailing list
> responsible for the file.  That way people know who to go to regarding
> issues with it.  This would be particularly important if downstreams will be
> providing their own files when upstream doesn't do so.
>
> Screenshots are available, but what about videos?
Richard wants to target that in a later revision of AppData

> Does the <id/> tag really need to have the .desktop extension?  Can't this
> be specified by the type?  So if it is "desktop" type, it can automatically
> add the .desktop extension.
In theory, yes - but I am not sure if it makes sense to change the
spec for this detail - maybe we can do that in a later revision. :-)

> For a more extreme question, is there a reason all this information cannot
> just be put into the .desktop file, or an additional .desktop file?  Why
> does this have to be an xml file?  It seems like a lot of the information is
> either parsed from the .desktop file or identical to the .desktop file.  Why
> can't we just extend the .desktop file spec, or include a modified
> special-purpose .desktop file, to handle the missing bits?  This will also
> solve issues like translation.
The nested screenshots are not possible with desktop-file-layout, as
well as the long-description & co.

Cheers,
    Matthias

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