<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 5, 2013 at 9:49 PM, Matthias Klumpp <span dir="ltr"><<a href="mailto:matthias@tenstral.net" target="_blank">matthias@tenstral.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2013/11/5 Todd <<a href="mailto:toddrjen@gmail.com">toddrjen@gmail.com</a>>:<br>
> [...]<br>
<div class="im">> Looking at the spec, I have a few suggestions:<br>
</div>(I assume you mean the AppStream spec)<br>
<div class="im">> For <project_group/>, I think it would be good to allow arbitrary groups<br>
> rather than limiting it to only a few recognized groups. This is another<br>
> gatekeeper issue: no project our group would have the authority to say which<br>
> group is and is not acceptable.<br>
</div>project_group allows arbitrary values already, the specs just say<br>
"known values include..." which is in no way a recommendation. And I<br>
am not planning to change that ;-)<br>
<div class="im"><br></div></blockquote><div><br></div><div>That isn't clear from the description.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> I also think sleeping multiple groups and/or sub-groups. KDE at least had<br>
> sub-groups like KDE edu, KDE multimedia, and calligra. I think it would be<br>
> good for apps to be able to identify themselves as belonging to one of these<br>
> groups. I could also see an application providing, say, gnome/KDE<br>
> integration that could benefit from belonging to both groups.<br>
</div>I think this would be overly confusing for users. Just say "KDE-Edu"<br>
or "KDE-Multimedia" would make some sense... But in all cases, the<br>
applications are part of the KDE umbrella project. Mozilla also has a<br>
"Mozilla Messaging" department, but it is still listed as "Mozilla".<br>
I am not sure of what value adding subgroups would bring to the users...<br>
<div class="im"><br></div></blockquote><div><br></div><div>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.<br>
<br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> I think it would be good too either have a change log tag or a<br>
> machine-parseable change log spec that would allow app stores to display the<br>
> change log (that is something that bothers me about YaST, you can only view<br>
> a change log after the app is installed). It needs to be in a reasonably<br>
> consistent format so the app store can extract the changes for the most<br>
> recent version, the date of the last release, and the most recent version<br>
> number. The Android app store provides this information, for example.<br>
</div>This is already done via PackageKit for the connected package.<br>
Including upstream information would require extra logic for parsing<br>
version numbers of every distribution, and it would require additional<br>
caches for chagelogs.<br>
I like the idea, but having distributor's changelogs is nicer at time.<br></blockquote><div><br></div><div>That would still require standardizing distributor's changelogs.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It also will be insanely difficult to get all app authors to write a<br>
machine-readable changelog and change the changelogs they are writing<br>
already.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Any more difficult than getting them to write appdata files?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> Regarding mimetypes, I recall there had been some concern over apps that get<br>
> their mimetypes dynamically either at build-time or runtime from other apps<br>
> or libraries. Might this be a good opportunity to find a solution to this?<br>
> As with the add-ons I mentioned previously, the app-store can either<br>
> atomically download these plugins or allow the user to download them. The<br>
> details would be left up to the implementation I assume.<br>
</div>This is slready done, some implementations exist :-)<br>
<div class="im"><br></div></blockquote><div><br></div><div>Okay, it doesn't seem to be widely used though.<br></div><div class="im"> <br>
> For a more extreme question, is there a reason all this information cannot<br>
> just be put into the .desktop file, or an additional .desktop file? Why<br>
> does this have to be an xml file? It seems like a lot of the information is<br>
> either parsed from the .desktop file or identical to the .desktop file. Why<br>
> can't we just extend the .desktop file spec, or include a modified<br>
> special-purpose .desktop file, to handle the missing bits? This will also<br>
> solve issues like translation.<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The nested screenshots are not possible with desktop-file-layout, as<br>
well as the long-description & co.<br>
<div class="im"><br></div></blockquote><div><br></div><div>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?".<br>
</div></div><br></div></div>