Adopting AppData in KDE?

[Todd]

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

> 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 ;-)
>
>
That isn't clear from the description.


>  > 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...
>
>
Amarok is a multimedia program under the KDE umbrella, but it is not a
KDE-multimedia app.  People who want to install the full Calligra suite
would probably want to get a list of all Calligra applications, not a list
of all KDE applications.

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


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

That would still require standardizing distributor's changelogs.


> 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.
>
>
Any more difficult than getting them to write appdata files?


>  > 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 :-)
>
>
Okay, it doesn't seem to be widely used though.

> 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.
>
>
Not in the current standard, the question is "what is the advantage is of
creating an entirely new standard with a lot of redundant information over
just extending the existing standard?".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20131106/e4251b87/attachment.htm>