<p dir="ltr"><br>
On Nov 5, 2013 6:42 PM, "Richard Hughes" <<a href="mailto:hughsient@gmail.com">hughsient@gmail.com</a>> wrote:<br>
><br>
> On 5 November 2013 17:37, Todd <<a href="mailto:toddrjen@gmail.com">toddrjen@gmail.com</a>> wrote:<br>
> >> Define ChangeLog? You mean what changed between versions?<br>
> > Yes, as well as the version number and date, probably.<br>
><br>
> I'd be open to ideas about this. Can you file an issue and we can talk<br>
> about possible ideas there.</p>
<p dir="ltr">Okay, but if this is going to be a separate file with outs own spec then it is probably outside the scope of this project.  But the two efforts could be coordinated.</p>
<p dir="ltr">> >> In this case you can specify the mimetypes in the desktop file.<br>
> > Yes, if you know beforehand what mimetypes your application will support.<br>
> > But this isn't always the case.<br>
><br>
> I don't think AppData can help you there.</p>
<p dir="ltr">I know, but this may be a good opportunity to see if there are any improvements that can be made to the existing desktop file spec as well.</p>
<p dir="ltr">> > Couldn't you just set another type for those?  Or, if the literal file name<br>
> > is not present, add a .desktop extension?  Anyway, although it is present in<br>
> > the example, this should probably be made explicit in the description.<br>
><br>
> Patches welcome :) The website source is in the appdata-tools repo as well.</p>
<p dir="ltr">But there is still the question of whether the extension should be hard-coded our based on the type.</p>
<p dir="ltr">> > The specification can be updated, though, right?  Can't new fields and<br>
> > valuetypes be added for those things?  It is a choice between extending an<br>
> > existing spec or creating an entirely new one.<br>
><br>
> Can you give an example of how you would squish a 3 paragraph, 100<br>
> word description with a few bullet points (translated into 7<br>
> languages) into a desktop file?</p>
<p dir="ltr">How is it any different in principle from putting it in an xml file?  Besides the fact that you can't put translations in the xml file.</p>
<p dir="ltr">And there is no reason there couldn't be a second, supplemental file for things like a description that might be too long to fit comfortably in the main file or might not be safely parsed by software expecting an old version of the spec.  There wouldn't be any disadvantage here compared to the xml file since you would still need an additional file, it would probably even be simpler since you would only need one additional file rather than one per language.</p>

<p dir="ltr">I think the main issues this would resolve are redundancy, and that this information might be useful outside of app stores.<br>
</p>