--047d7bf0da367562d504ea7061cf Content-Type: text/plain; charset=ISO-8859-1 On Nov 5, 2013 12:49 PM, "Weng Xuetian" wrote: > > On Monday, November 04, 2013 08:58:22 PM Richard Hughes wrote: > > On 4 November 2013 20:56, Weng Xuetian 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. --047d7bf0da367562d504ea7061cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


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=3Dtrue. That's probably a desktop-level cho= ice tho.
> It's not about NoDisplay, plasmoids is a kind of widgets on KDE de= sktop, 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 some= how 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 s= pec?=A0 An application can list itself as supporting certain add-on categor= ies, and an add-on can identify itself as belonging to one or more such cat= egories.

So, for example plasma workspaces could accept widgets, wall= papers, 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 wo= uld 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 apple= t, and some using plasmoid.

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

--047d7bf0da367562d504ea7061cf--