Adopting AppData in KDE?

[Todd]

On Nov 5, 2013 6:42 PM, "Richard Hughes" <hughsient at gmail.com> wrote:
>
> On 5 November 2013 17:37, Todd <toddrjen at gmail.com> wrote:
> >> Define ChangeLog? You mean what changed between versions?
> > Yes, as well as the version number and date, probably.
>
> I'd be open to ideas about this. Can you file an issue and we can talk
> about possible ideas there.

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.

> >> In this case you can specify the mimetypes in the desktop file.
> > Yes, if you know beforehand what mimetypes your application will
support.
> > But this isn't always the case.
>
> I don't think AppData can help you there.

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.

> > Couldn't you just set another type for those?  Or, if the literal file
name
> > is not present, add a .desktop extension?  Anyway, although it is
present in
> > the example, this should probably be made explicit in the description.
>
> Patches welcome :) The website source is in the appdata-tools repo as
well.

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

> > The specification can be updated, though, right?  Can't new fields and
> > valuetypes be added for those things?  It is a choice between extending
an
> > existing spec or creating an entirely new one.
>
> 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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20131105/1e83aa77/attachment.htm>