Adopting AppData in KDE?

[Todd]

On Nov 5, 2013 5:18 PM, "Todd" <toddrjen at gmail.com> wrote:
>
>
> On Nov 5, 2013 12:49 PM, "Weng Xuetian" <wengxt at gmail.com> wrote:
> >
> > On Monday, November 04, 2013 08:58:22 PM Richard Hughes wrote:
> > > On 4 November 2013 20:56, Weng Xuetian <wengxt at gmail.com> wrote:
> > > > Some questions:
> > > > 1. What about non-application case?
> > >
> > > In GNOME we only consider an application to have a desktop file
> > > without NoDisplay=true. That's probably a desktop-level choice tho.
> > It's not about NoDisplay, plasmoids is a kind of widgets on KDE
desktop, it
> > also use desktop file to store metadata, though it's not sit in
> > share/applications but some kde private folder. But each small widget
is like
> > an small application.
> >
> > 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?
>
> 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 plasmoid.
>
> 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,
though.
Looking at the spec, I have a few suggestions:

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

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