<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 5 March 2013 12:41, Jerome Leclanche <span dir="ltr"><<a href="mailto:adys.wh@gmail.com" target="_blank">adys.wh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

 - PNG is a massively popular file format, who the hell thought this was a good idea?</blockquote></div><br></div><div class="gmail_extra">Seconded ;-)<br><br></div><div class="gmail_extra">Bastien:<br>> Your implementation returns results differently from the one we use in<br>


> shared-mime-info itself.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Looking at the implementation in PyXDG, it's quite a long way from the recommended checking order in the spec. I'll have to sort that out properly when I've got time, but for now it should be improved by making the first suffix from the globs file win, not the last one (they're sorted by decreasing weight).<br>

<br></div><div class="gmail_extra">Jerome:<br><div>> I think resulting behaviour should be the same as what you would do
 when getting two conflicting, same-priority magics. The spec doesn't 
seem to advocate a behaviour in this case[1]. In general, if there are 
conflicts, they should be solved using the priority attribute at the 
package level.<br><br></div><div>In the file structure, the priority attribute is a property of the magic matching rule, not of the mimetype. The description in the spec, on the other hand, seems to be relevant to the Mimetype overall: "Low
numbers should be used for more generic types (such as 'gzip compressed data')
and higher values for specific subtypes (such as a word processor format that
happens to use gzip to compress the file)."<br><br></div><div>So does it make sense to use this even when we're not using the magic matching rules?<br><br>Thanks,<br></div><div>Thomas<br></div>

</div></div>