[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Adopting AppData in KDE?
From: Todd <toddrjen () gmail ! com>
Date: 2013-11-05 16:18:19
Message-ID: CAFpSVpJ2QW9bNJNKrGuUisTZyG5GcMAf3VvX09rXysWvvn-JHw () mail ! gmail ! com
[Download RAW message or body]
On Nov 5, 2013 12:49 PM, "Weng Xuetian" <wengxt@gmail.com> wrote:
>
> On Monday, November 04, 2013 08:58:22 PM Richard Hughes wrote:
> > On 4 November 2013 20:56, Weng Xuetian <wengxt@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.
[Attachment #3 (text/html)]
<p dir="ltr"><br>
On Nov 5, 2013 12:49 PM, "Weng Xuetian" <<a \
href="mailto:wengxt@gmail.com">wengxt@gmail.com</a>> wrote:<br> ><br>
> On Monday, November 04, 2013 08:58:22 PM Richard Hughes wrote:<br>
> > On 4 November 2013 20:56, Weng Xuetian <<a \
href="mailto:wengxt@gmail.com">wengxt@gmail.com</a>> wrote:<br> > > > \
Some questions:<br> > > > 1. What about non-application case?<br>
> ><br>
> > In GNOME we only consider an application to have a desktop file<br>
> > without NoDisplay=true. That's probably a desktop-level choice tho.<br>
> It's not about NoDisplay, plasmoids is a kind of widgets on KDE desktop, \
it<br> > also use desktop file to store metadata, though it's not sit in<br>
> share/applications but some kde private folder. But each small widget is \
like<br> > an small application.<br>
><br>
> What I care is a app center doesn't only have application, it somehow \
should<br> > contains plugin to other application, for example, a browser plugin, \
a widget<br> > on desktop. And it makes sense if they don't have desktop \
file.<br> ><br>
> Can AppData handle such case?</p>
<p dir="ltr">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.</p>
<p dir="ltr">So, for example plasma workspaces could accept widgets, wallpapers, \
runners, desktop effects, kwin scripts, shells, etc.</p> <p dir="ltr">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.</p> \
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic