Adopting AppData in KDE?


I've been asked by Richard Hughes from Gnome and Fedora to raise the
profile of using AppData metadata within KDE. I know very little
about this area myself, but thought it was worthwhile raising on the
list for discussion. If you have any questions about AppData then
Richard would be happy to answer them, so please cc him on replies.

The AppData justification, file format and tools are documented at
[1]. AppData and AppStream are slowly being adopted by various
distros for use in their software installers and app stores. The
AppData metadata file supplements the .desktop file by having a long
description of an app, links to some screenshots, and the app home
page, which get dispalyed in the app installer. The description can
also be localized. While distro's could generate and maintain this
data for themselves, to do so would be very time consuming for them,
may not present the app in the best way possible, and would quickly
get outdated. It makes a lot of sense for apps to create and maintain
this metadata for themselves, presenting themselves in the best way
possible, which all the distros can then reuse in their installer

As far as I'm aware, AppData and/or AppStream is either used or
scheduled to be used by default in Gnome Software Centre, Apper,
Fedora, and OpenSuse, and optionally in several other distros, so is
not a distro specific intiative. I think there's even OBS integration
happening. If anyone knows more or thinks differently please let us

Some recent developments make this a fairly high priority for apps
that wish to target a cross-desktop audience. The new Gnome Software
Centre in Gnome 3.12 which uses AppData will become the default
installer in Fedora 20 for Gnome (Fedora KDE will use Apper).
Currently apps that don't provide AppData are ranked lower in search
results in Gnome Software, but from Gnome 3.14 such apps will not be
listed at all [2]. This means that without an AppData file KDE apps
will eventually not be visible to Gnome users in their default app
installer. Currently Gnome has 50% of apps covered and is
coordinating an effort for full coverage [3], but KDE has only 1%.

Obviously individual apps are free to add these files [4], but from a
KDE-wide perspective we need to discuss if we want to officially adopt
this as a requirement, and if we want to provide a more coordinated
and standardized solution. What do people think?

If we do adopt it, the two obvious issues to me are localization and
screenshots. Ideally scripty would be hooked up to generate the
translation files, but as they are an XML format it may need a bit of
work. Scripty would also need the AppData file to be in a standard
location in each repo. The screenshots need to be hosted by the app
(at least initially, Fedora copy the screenshots to their own server
later to save load), so we may want to have somewhere common on the
KDE infrastructure for that. I'd also suggest defining a file naming
standard including the app name and version number in the screenshot

Taking a slight step-back, I wonder if there is a need for a more
generic KDE metadata file in each KDE repo that describes even more
useful info, like module, maintainer, reviewboard, bugzilla, last
stable release number, frameworks tier, forums, irc channel, userbase,
mailing list, etc, that AppData and projects.xml and inqlude and any
other required metadata files could all be automatically generated

One obvious question is how this might relate to Bodega if KDE chooses
to switch to that? What does Gnome shipping their own official "App
Store" mean for cross-distro/cross-desktop app store efforts and do we
need to start working on our own now, or will Bodega fill that need
for us?



[1] <a href="" title=""></a>
[2] <a href="" title=""></a>
[3] <a href="" title=""></a>
[4] <a href="" title=""></a>


Re: Adopting AppData in KDE?

By Weng Xuetian at 11/04/2013 - 16:56

Some questions:
1. What about non-application case?
KDE plasmoid, and some kcm worked as a plugin in system setttings, some of
them also present a desktop, which doesn't theoratically an application, but I
think should be able to install from app center.

2. What if an application doesn't actually have an window, or a big enough
window can be put in screenshot? Like a minimal media player stay in tray.

On Saturday, November 02, 2013 09:27:18 AM John Layt wrote:

Re: Adopting AppData in KDE?

By Richard Hughes at 11/04/2013 - 16:58

On 4 November 2013 20:56, Weng Xuetian < ... at gmail dot com> wrote:
In GNOME we only consider an application to have a desktop file
without NoDisplay=true. That's probably a desktop-level choice tho.

I guess do the best you can and use the stock KDE fonts, wallpapers
and that kind of thing wherever possible.


Re: Adopting AppData in KDE?

By Weng Xuetian at 11/04/2013 - 17:29

On Monday, November 04, 2013 08:58:22 PM Richard Hughes wrote:
What I care is a app center doesn't only have application, it somehow should
contains plugin to other application, for example, a browser plugin, a widget
on desktop. And it makes sense if they don't have desktop file.

Can AppData handle such case?

Is it possible for an application not providing any screenshot?


Re: Adopting AppData in KDE?

By Todd at 11/05/2013 - 12:18

On Nov 5, 2013 12:49 PM, "Weng Xuetian" < ... at gmail dot com> wrote:
Would it make sense to have this explicitly defined in the spec? An
application can list itself as supporting certain add-on categories, and an
add-on can identify itself as belonging to one or more such categories.

So, for example plasma workspaces could accept widgets, wallpapers,
runners, desktop effects, kwin scripts, shells, etc.

Then the app center could provide a way to list all add-ons of a particular
type for a particular app. How this would be represented would depend on
the app center implementation.

It wouldn't strictly be necessary for the application to explicitly define
its add-on categories, but doing so guarantees naming is consistent. For
example it avoids some apps using widget, some using applet, and some using

I know the android play store has something like this as well, where an
application can open a special limited play store that only lists add-ons
for itself, add-ons that may or may not be listed separately in the play
store as well. I don't know the details of how this is decided by the app,

Re: Adopting AppData in KDE?

By Todd at 11/05/2013 - 13:12

On Nov 5, 2013 5:18 PM, "Todd" < ... at gmail dot com> wrote:
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.

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 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

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.

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?

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.

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.

Re: Adopting AppData in KDE?

By Matthias Klumpp at 11/05/2013 - 16:49

2013/11/5 Todd < ... at gmail dot com>:

Re: Adopting AppData in KDE?

By Todd at 11/06/2013 - 04:30

On Tue, Nov 5, 2013 at 9:49 PM, Matthias Klumpp < ... at tenstral dot net>wrote:

I am not sure how it would be confusing, the app store could list all
applications under a particular umbrella, as well as groups under that

That would still require standardizing distributor's changelogs.

Re: Adopting AppData in KDE?

By Matthias Klumpp at 11/05/2013 - 16:53

In order to solve the translation-issues: I think KDE could very well
use Scripty to insert translations into the AppData files. However, I
am currently thinking about adding a new element to specify a
gettext-domian to fetch trabslations from. The problem is that, in
order for the AppStream generator to do the translation, the gettext
files would have to be shipped with the same package, which might not
always be the case, if you have language-packages.
So I don't think this would work.
Are there other suggestions on how to make trabslating AppData files
easier for KDE?

Re: Adopting AppData in KDE?

By T.C. Hollingsworth at 11/05/2013 - 23:49

On Tue, Nov 5, 2013 at 1:53 PM, Matthias Klumpp < ... at tenstral dot net> wrote:
I wrote a draft patch to do this already:
<a href=";m=138353976230003&amp;w=2" title=";m=138353976230003&amp;w=2">;m=138353976230003&amp;w=2</a>

There's a bit of a problem though, that Yuri pointed on on kde-i18n-doc:

On Mon, Nov 4, 2013 at 11:34 PM, Yuri Chornoivan < ... at ukr dot net> wrote:
Unfortunately, the schema says the latter is invalid. Is the schema
wrong or intltool wrong?

If we have to do it by paragraph, having scripty merge the
translations back into the original XML is going to be ugly...

Definitely not for KDE, we ship all our translations separately from
the main package for stuff in the SC.

Could we just ship the .mo files in /usr/share/app-info/locale or so
and just have the extractors copy those files unconditionally (e.g.
regardless of the existence of a .desktop file) when trawling through


Re: Adopting AppData in KDE?

By Richard Hughes at 11/06/2013 - 04:40

On 6 November 2013 03:49, T.C. Hollingsworth < ... at gmail dot com> wrote:
This is what we do in GNOME:
<a href="" title=""></a>
gets translated by intltool into
<a href="" title=""></a>
-- so we have a document structure like:

Software allows you to find and install new applications and system
extensions and remove existing installed applications.
<p xml:lang="cs">
Aplikace Software umožňuje vyhledávat a instalovat aplikace a
systémová rozšíření a odebírat stávající nainstalované aplikace.

The reasons I chose to do it this way were mainly because most
translators hate translating XML tags. And if one translator does
something slightly wrong, the whole document becomes invalid. For
instance, asking the translators to translate this source string:

<p>This is the list of features:</p><ul><li>Massive color database</li></ul>

If they translate this as:

<p>This is the list of features:</p><ul><<li>Massive colour database</li></ul>

This fails hard when the document is installed (as in, fails to parse,
and so doesn't get used). Most translators won't validate the
resulting XML document before translating. In GNOME we'd ask them to
translate "This is the list of features:" and "Massive color database"
which is much more sane and basically impossible to get wrong.

If you have a translation tool that is able to somehow rebuild the tag
structure and only ask the translators to actually translate the prose
then I suppose supporting something like <description xml:lang="cs">
in AppData makes sense, but only if it takes more than one translator
replacing <p> with «p»  to screw things up.

I'm not sure how well this will work, at least in gnome-software we
allow the user to match on a keyword cache using the "C" name, and
also the UTF8 and normalized versions of their current locale. I also
don't think the extractor tools (from desktop+appdata->AppStream
metadata) are going to be able to switch locale like that, and reading
the gmo files manually isn't something I'd look forward to


Re: Adopting AppData in KDE?

By T.C. Hollingsworth at 11/06/2013 - 16:51

On Wed, Nov 6, 2013 at 1:40 AM, Richard Hughes < ... at gmail dot com> wrote:
Nah, I meant for the extractor tools to read in the translations into
the big giant AppStream XML; no magic needed in the software centers,
nor would there be any need for users to have to have the package that
has these .mo files installed, which kind of defeats the purpose.

The gettext module built in to Python can read in translations from
arbitrary domains in arbitrary languages sourcing locale files from
arbitrary directories no sweat, so this would be a fairly simple patch
to fedora-appstream. (I'm happy to resubmit this suggestion in patch
form too, BTW; just wanted to make sure it was something you were
interested in implementing, first. ;-)

I was originally going to suggest we do something like this but with
seperate <application xml:lang="foo"> XML fragments instead of po
files, just to make things simpler in the appstream extractor, but
after looking at what it took to get such XML output from KDE po files
I discovered that the gettext goop to implement this in
fedora-appstream itself isn't really any more complicated than the
etree goop to suck it out of those XML fragments instead. Doing it
this way also has the side effect of ensuring that translators never
need to deal with XML, ever.

In general I think being able to ship translations separately would be
a big improvement to the i18n story for all the software centers that
implement this spec. It has more benefits than just aiding KDE in
implementing it.

For instance, in Fedora we're probably going to be stuck with having
AppData included as SourceN files in SRPMs for quite some time. At
the moment, translation of those is pretty much impossible. Hooking a
bunch of random SRPMs up to Transifex would suck, as would trying to
merge back translations into the XML files in Fedora dist-git in some
automated fashion. But with something like this it would be fairly
easy to extract all the appdata.xml files shipped as additional
sources in SRPMs, dump it in Fedora's transifex instance, and get them
back out and working in GNOME Software and Apper with minimal

Also, I suspect that you don't want GNOME Software in other languages
to be a hairball of that language and English forever, so you're
probably going to want to turn off display of apps that aren't
translated at some point. You could say that "hey, obviously upstream
doesn't support that language very well, so including it in the app
center in that locale is pretty useless", which would be true to some
extent, but that ignores multilingual users who prefer to use their
computer in their native language but are happy to use an app in
English if it's awesome enough. (There are a lot of English-only dev
tools, for instance. I'd hate to lose would-be free software
contributors just because they prefer their desktop to be in their
native tongue.)

Adding a "show me a mishmash of Esperanto and English plz" checkbox is
really a terrible option, so if we want to have complete coverage of
translated application data in the future—and I think we really
do—we're going to have to have infrastructure for distro translators
to pick up the slack, and this would be a big head start.


Re: Adopting AppData in KDE?

By Richard Hughes at 11/06/2013 - 17:38

On 6 November 2013 20:51, T.C. Hollingsworth < ... at gmail dot com> wrote:
No, if this is the case then I've failed. I want the AppData files to
live upstream, controlled and modified by the maintainers, and
translated by the upstream translators. I'm only accepting files into
fedora-appstream that have been sent upstream while we're waiting for
a new upstream release. For instance:
<a href="" title=""></a>

No, this isn't a Fedora "problem", this is an upstream feature. If we
hide all the translations in Fedora then we're no better than
canonical with the Ubuntu Software Center application data.

That wasn't in my plans, no.


Re: Adopting AppData in KDE?

By Kevin Krammer at 11/06/2013 - 04:55

On Wednesday, 2013-11-06, 08:40:56, Richard Hughes wrote:
This sounds more like a problem in translator tooling, commit hooks and CI

Anyway, couldn't you still generate the XML with language selectors on the
main elements themselves?
Since you already put markup-less strings into the file, why not just add the
language attribute to, e.g. desscription, and then fill the tags with content?

Do you expect to support partial translations? I.e. one paragraph translated,
followed by an untranslated one?


Re: Adopting AppData in KDE?

By Richard Hughes at 11/06/2013 - 08:55

On 6 November 2013 08:55, Kevin Krammer < ... at kde dot org> wrote:
Sure, we support that. Imagine the following paragraphs in locale C:

<p>This is what the color management program does:</p>
<ul><li>It's awesome</li></ul>

And translating that to en_GB, I only need to translate the first
paragraph ("color" -> "colour"). The same thing happens all the time
with the other languages based on other languages, e.g. pt_BR and that
kind of thing.


Re: Adopting AppData in KDE?

By Kevin Krammer at 11/06/2013 - 09:00

On Wednesday, 2013-11-06, 12:55:40, Richard Hughes wrote:
Hmm, well the GB tranlator could just copy the string.

It just looked a lot like HTML and certain things don't make the same sense in
all languages, e.g. <b> does not necessarily apply to east asian glyphs and
translators would need to be able to change that to something else.

But I guess you don't have any actual markup in there, so no need to allow
translators to change it.


Re: Adopting AppData in KDE?

By Daniel Nicoletti at 11/05/2013 - 18:02

2013/11/5 Matthias Klumpp < ... at tenstral dot net>:

Re: Adopting AppData in KDE?

By Richard Hughes at 11/05/2013 - 13:21

On 5 November 2013 17:12, Todd < ... at gmail dot com> wrote:
I think restricting it to the desktops specified in the menu-spec makes sense.

Define ChangeLog? You mean what changed between versions?

In this case you can specify the mimetypes in the desktop file.

That's what <update_contact> is used for.

Already filed: <a href="" title=""></a>

No, as we'll be supporting other kinds of desktop applications in he
future, e.g. glick2 bundles and that kind of thing.

You can't put multiline descriptions in a desktop file, or have
multiple screenshots with localized captions, unless you *really*
start to abuse the specification.


Re: Adopting AppData in KDE?

By Todd at 11/05/2013 - 13:37

Re: Adopting AppData in KDE?

By Richard Hughes at 11/05/2013 - 13:42

On 5 November 2013 17:37, Todd < ... at gmail dot com> wrote:
I'd be open to ideas about this. Can you file an issue and we can talk
about possible ideas there.

I don't think AppData can help you there.

Patches welcome :) The website source is in the appdata-tools repo as well.

Can you give an example of how you would squish a 3 paragraph, 100
word description with a few bullet points (translated into 7
languages) into a desktop file?


Re: Adopting AppData in KDE?

By Todd at 11/05/2013 - 14:42

On Nov 5, 2013 6:42 PM, "Richard Hughes" < ... at gmail dot com> wrote:
Okay, but if this is going to be a separate file with outs own spec then it
is probably outside the scope of this project. But the two efforts could
be coordinated.

I know, but this may be a good opportunity to see if there are any
improvements that can be made to the existing desktop file spec as well.

But there is still the question of whether the extension should be
hard-coded our based on the type.

How is it any different in principle from putting it in an xml file?
Besides the fact that you can't put translations in the xml file.

And there is no reason there couldn't be a second, supplemental file for
things like a description that might be too long to fit comfortably in the
main file or might not be safely parsed by software expecting an old
version of the spec. There wouldn't be any disadvantage here compared to
the xml file since you would still need an additional file, it would
probably even be simpler since you would only need one additional file
rather than one per language.

I think the main issues this would resolve are redundancy, and that this
information might be useful outside of app stores.

Re: Adopting AppData in KDE?

By Richard Hughes at 11/05/2013 - 15:59

On 5 November 2013 18:42, Todd < ... at gmail dot com> wrote:
Well, I'm not saying it's out of scope for AppData, I'm simply saying
it needs discussing.

There's no question. The full ID is the basename of the primary thing
used to generate the data. Fonts have full IDs ending in .ttf for

You really can. It's very easy to do in GNOME, and we've been doing it
for years.

Err, this is the compiled (i.e. what's installed, rather than what's
in the repo) file for gnome-software:
<a href="" title=""></a>

AppData was designed for app stores.


Re: Adopting AppData in KDE?

By Richard Hughes at 11/05/2013 - 04:28

On 4 November 2013 21:29, Weng Xuetian < ... at gmail dot com> wrote:
Then I suppose it makes sense to ship an AppData file. How does a
plasmoid register itself as available? I'll likely have to create a helper in the appstream extractor code.

Sure. The only thing not covered in AppData for this case is an icon,
but that would be a very easy adjustment to the specification.

Sure, screenshots are a nice-to-have not mandatory.


Re: Adopting AppData in KDE?

By Aaron J. Seigo at 11/05/2013 - 08:06

On Tuesday, November 5, 2013 08:28:08 Richard Hughes wrote:
plasmapkg -i <pathtopackage>

Re: Adopting AppData in KDE?

By Richard Hughes at 11/05/2013 - 08:08

On 5 November 2013 12:06, Aaron J. Seigo < ... at kde dot org> wrote:
Sure, but what does that do? Does that copy a file in a special
directory or something?


Re: Adopting AppData in KDE?

By Aaron J. Seigo at 11/05/2013 - 08:18

On Tuesday, November 5, 2013 12:08:57 Richard Hughes wrote:
it should be of no concern to the installer. what it does is an implementation
detail. it may even change between major versions, as it already has
(admittedly in a backwards-compatible manner) between 4.x and 5.x due to the
deprecation of ksycoca4. that is why plasmapkg is provided in the first place.

why do you need to know this? can AppStream not call external tools to do the

Re: Adopting AppData in KDE?

By Richard Hughes at 11/05/2013 - 08:57

On 5 November 2013 12:18, Aaron J. Seigo < ... at kde dot org> wrote:
The way AppStream is generated in Fedora is we:

* Take the binary rpm file
* Explode it somewhere (without installing it)
* Parse the contents
* Write a file of metadata and a tarfile of icons


Re: Adopting AppData in KDE?

By Aaron J. Seigo at 11/05/2013 - 10:40

On Tuesday, November 5, 2013 12:57:28 Richard Hughes wrote:
ok ... this is separate from App Data, then?

the corresponding steps for a plasma package would be:

* take the compressed package file
* unzip it somewhere (without installing it)
* parse the metadata.desktop file in the root
* optionally look for icons in the root
* write a file of metadata and a tarfile of icons

it’s just a zip file. :)

<a href="" title=""></a>

Re: Adopting AppData in KDE?

By Matthias Klumpp at 11/05/2013 - 13:11

2013/11/5 Aaron J. Seigo < ... at kde dot org>:
The case of installing Plasmoids would actually be handled by
something like Listaller (but I think even for that it would be out of
scope, since plasmapkg already exists - this might make some sense to
implement it in KDE software-centers only and enhance the AppStream
data with an application type (like type="plasmoid"))

Re: Adopting AppData in KDE?

By Christoph Feck at 11/04/2013 - 13:32


what would be nice to have is information about which MIME types an
application can read and write.

Christoph Feck (kdepepo)
KDE Quality Team

Re: Adopting AppData in KDE?

By Matthias Klumpp at 11/04/2013 - 15:08

2013/11/4 Christoph Feck < ... at maxiom dot de>:

Re: Adopting AppData in KDE?

By Richard Hughes at 11/04/2013 - 14:57

On 4 November 2013 17:32, Christoph Feck < ... at maxiom dot de> wrote:
This is already in the .desktop file, and is thus extracted into the
AppStream metadata.


Re: Adopting AppData in KDE?

By Yuri Chornoivan at 11/02/2013 - 07:00


1. AppData files are tailored for intltool/its-tool processing (tags with underscores). What do you think about adding untranslatable by design appdata files like it was done for Audacity [1]?
2. AppData in GNOME packages is filled with translations while compiling/packaging the application. Can it be somehow aligned with KDE idea of storing translations in separate repo?
3. Is it technically possible to have appdata.xml in repo translated by scripty based on KDE desktop- POs (just like KDE .desktop files)?
4. What is planned to do with Debian/Ubuntu DDTP translations [2, 3]? Is there any plans to adopt it for Canonical Software Centre/Muon with some kind of backend? Is it yet another almost-standard for RPM/GNOME distributions?

Thanks in advance for your answers.

Best regards,

[1] <a href="" title=""></a>
[2] <a href="" title=""></a>
[3] <a href="" title=""></a>

Re: Adopting AppData in KDE?

By Richard Hughes at 11/02/2013 - 10:25

On 2 November 2013 11:00, Yuri Chornoivan < ... at ukr dot net> wrote:
Well, this is fine if you speak en_GB or en_US, but that's only a tiny
proportion of the desktop Linux users these days. It's certainly
better than nothing, but if you don't speak English it's not helpful
at all.

I'm not sure how KDE does this on a technical level, but I'm sure you
could merge the XML file together somehow if you didn't want the intltool method.

No clue on this, sorry.

No, packages are a different problem to applications. In the case you
have multiple applications shipped in one package you want separate
descriptions, not one description that's a mix of the two. Plus, if we
want non-packaged applications (for instance listaller, glick2 or
click bundles) then the concept of a package description looses all

There's nothing inherently GNOME or RPM specific about this at all in
my opinion.


Re: Adopting AppData in KDE?

By Matthias Klumpp at 11/02/2013 - 10:34

2013/11/2 Richard Hughes < ... at gmail dot com>:

Re: Adopting AppData in KDE?

By Richard Hughes at 11/02/2013 - 10:38

On 2 November 2013 14:34, Matthias Klumpp < ... at tenstral dot net> wrote:
Depends on the format, have you got any examples of what it looks like?


Re: Adopting AppData in KDE?

By Yuri Chornoivan at 11/02/2013 - 11:10

написане Sat, 02 Nov 2013 16:38:48 +0200, Richard Hughes
< ... at gmail dot com>:

An example attached.


Re: Adopting AppData in KDE?

By Richard Hughes at 11/02/2013 - 11:17

On 2 November 2013 15:10, Yuri Chornoivan < ... at ukr dot net> wrote:
Well, <strong> isn't a recognised tag (See
<a href="" title=""></a>) but
using xml:lang="foo" is exactly what intltool produces as an output


Re: Adopting AppData in KDE?

By Albert Astals Cid at 11/02/2013 - 15:33

El Dissabte, 2 de novembre de 2013, a les 09:27:18, John Layt va escriure:
What's the point in having an installer that hides more than half of the apps
in the world that don't ship a file that is not a standard and doesn't seem to
me it was developed as a standard? How is this useful to the end user?


Re: Adopting AppData in KDE?

By Richard Hughes at 11/02/2013 - 15:48

On 2 November 2013 19:33, Albert Astals Cid < ... at kde dot org> wrote:
We want to showcase high quality applications with active upstream
maintainers. There's no point us showing 5000 application where half
don't work or are abandonware. Also, I'm hoping AppData does become a
standard. It's already used by over 200 projects.


Re: Adopting AppData in KDE?

By Albert Astals Cid at 11/03/2013 - 07:59

El Dissabte, 2 de novembre de 2013, a les 19:48:01, Richard Hughes va
I've never created a standard so I can't comment on how to do it properly, but
writing it and then "threatening" to exclude from package managers those that
don't adopt it doesn't seem to be a way to start a discussion to me.


Re: Adopting AppData in KDE?

By Richard Hughes at 11/03/2013 - 08:22

On 3 Nov 2013 11:59, "Albert Astals Cid" < ... at kde dot org> wrote:
This is what we've decided to do in GNOME, KDE is free to decide any policy
it wants. We've decided that 500 high quality applications are better than
3000 broken ones.

KDE is free to ignore AppData if it chooses, although I think a large
number of people think the metadata is worthwhile to add.


Re: Adopting AppData in KDE?

By Sven Brauch at 11/03/2013 - 09:30

On Sunday 03 November 2013 12:22:52 Richard Hughes wrote:
Assuming KDE did that, then we would end up with a situation where you can't
easily install Krita in distributions that ship GNOME, and you can't easily
install Inkscape in distributions that ship KDE. That's a horrible situation,
because a lot of people do that as of today. It would further widen the
(technical) gap between the desktop environments, instead of encouraging
people to select the best application for what they want to do regardless of
what toolkit it uses (which I consider a somewhat idiotic criterion).
There would be lots of confused users in internet forums asking for why
$application is not available any more, and we'd be sitting there explaining
how to jump through hoops to still install it.
Thus I would claim that this is not an acceptable option.

Quality control should happen at the packager level. Broken applications
should not be available in the distribution's main repository. And
distributions should make the choice which application is good enough for
their users, not a desktop environment. Besides, as said multiple times, this
spec does not provide any kind of quality control worth mentioning anyways.
The level of quality control it achieves is on par with looking at the date
of the last commit in the repository.

For the same reasons, in my opinion, not showing packages in a package
manager which don't provide screenshots because they don't look pretty is a
bad choice. Of course this is your decision though.
In any case, it's a very bad precondition for discussing the new
specification for the reasons Albert mentioned.


Re: Adopting AppData in KDE?

By Richard Hughes at 11/03/2013 - 09:50

On 3 November 2013 13:30, Sven Brauch < ... at googlemail dot com> wrote:
I don't think that's true at all. Krita and Inkscape are two of the
killer apps I'd love to feature more prominently in GNOME Software.

I don't agree. Packages are just an implementation detail, as
gnome-software supports webapps and will soon support other staticly
linked packages like listaller and glick2.

I know for a fact that a lot of the GNOME developers use and love a
lot of KDE software, so I don't know why there is any kind of issue

Blender already has an AppData file in fedora-appstream, which has
also been submitted upstream for the next release.


Re: Adopting AppData in KDE?

By Sven Brauch at 11/03/2013 - 10:08

On Sunday 03 November 2013 13:50:05 Richard Hughes wrote:
Yes, and of course both applications would do anything it takes to get listed
in the package manager. Still, if KDE would go with its own thing it would be
unnecessarily painful. I just wanted to say that KDE doing its own thing is a
kind of virtual option since nobody would profit from it.

We're probably getting into a fight over uninteresting details here, sorry for
bringing them up. I just wanted to make two points, which are
- looking for this metadata file is not a good way to ensure quality
- I like the spec but I do not like the way it is presented to KDE.

On Sunday 03 November 2013 15:04:16 Felix Rohrbach wrote:

Re: Adopting AppData in KDE?

By david at 11/03/2013 - 10:09

The whole discussion of whether gnome excludes apps without app-data
will improve the quality of those listed is sort of a moot topic.

We could do with this having this sort of metadata available for all KDE apps;

and in fact we already maintain this sort of data to build the pages
at <a href="" title=""></a>

<a href="" title=""></a>
-> <a href="" title=""></a>
images are all at <a href="" title=""></a>

I fully support app developers helping keep this up to date and given
we already have this information, the idea of writing a small script
to convert this to the relevant XML (which to me seems a sensible
spec) should be simple enough.

That means we get Gnome app centre support, and if Muon want to use
that spec - that'd be great too.


Re: Adopting AppData in KDE?

By Alex Fiestas at 11/03/2013 - 10:44

On Sunday 03 November 2013 15:09:13 David Edmundson wrote:
As far as I know Muon-packagekit is already using it (ot it s planned at

Re: Adopting AppData in KDE?

By Lukas Appelhans at 11/04/2013 - 07:21

Hey! :)

We (Muon) currently use AppStream in the PackageKit-Plugin, which is about to
be merged into master.

Adopting AppData would give us a lot more data about applications, which would
be awesome, as we currently lack e.g. long application descriptions.

I don't really care much about spec details, but as long as it is used by
AppStream as well, it is cool for me! :)


El Domingo 03 noviembre 2013 06:44:56 Àlex Fiestas escribió:

Re: Adopting AppData in KDE?

By Albert Astals Cid at 11/03/2013 - 08:32

El Diumenge, 3 de novembre de 2013, a les 12:22:52, Richard Hughes va
As already other people proved in this thread, having appdata means nothing
about quality, it just means whoever released the app caved to your threat of
removing the app from the package manager if it does not have that magic file.

The fact that you keep repeating it, does makes not it true.

I am all for listing "high quality applications", it's just that this just
doesn't help.


Re: Adopting AppData in KDE?

By Richard Hughes at 11/03/2013 - 09:24

On 3 November 2013 12:32, Albert Astals Cid < ... at kde dot org> wrote:
Sure it does. We're not going to get AppData files for sodipodi,
cinepaint or arora any time soon. I don't think _having_ an AppData
file makes an application high quality, but we can probably say the
opposite is true in about 2-3 years.


Re: Adopting AppData in KDE?

By Albert Astals Cid at 11/03/2013 - 11:28

El Diumenge, 3 de novembre de 2013, a les 13:24:40, Richard Hughes va
But you said anyone can write one and submit it to Fedora for submission, you
also said they're pretty trivial to write, so why do you think I (or someone
else) can not write one for sodipodi and submit it?