On Nov 5, 2013 5:18 PM, "Todd" <toddr...@gmail.com> wrote: > > > On Nov 5, 2013 12:49 PM, "Weng Xuetian" <wen...@gmail.com> wrote: > > > > On Monday, November 04, 2013 08:58:22 PM Richard Hughes wrote: > > > On 4 November 2013 20:56, Weng Xuetian <wen...@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.
