On Tue, Nov 5, 2013 at 9:49 PM, Matthias Klumpp <matth...@tenstral.net>wrote:
> 2013/11/5 Todd <toddr...@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?".