<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
On Wednesday, February 17, 2021 9:53 AM, <span style="font-size: 11pt; color: rgb(0, 0, 0); font-family: Calibri, sans-serif;">Thomas Kluyver <thomas@kluyver.me.uk> wrote:</span></div>
<blockquote style="margin-top:0;margin-bottom:0">
<div id="divRplyFwdMsg" dir="ltr">I can see what you're saying, but I don't think it's ridiculous to suggest that a desktop file could encode some indication of how well an application handles a particular file type. You could think of this as describing 'can
open' vs 'can import'. A few more examples from my laptop of technically possible matches that you probably wouldn't want to be used by default:<br>
</div>
</blockquote>
<div>
<div>
<ul>
<ul>
<li>Libreoffice Writer & text/plain<br>
</li><li>Libreoffice Draw & application/pdf<br>
</li><li>Pinta (bitmap graphics editor) & image/svg<br>
</li><li>File roller (archive manager) & application/x-chrome-extension<br>
</li></ul>
</ul>
<div>I don't have a problem in principle with giving desktop files a way to express a quality of support measure for the various MIME types they can handle. That's about the capabilities of the software, not about system policy, notwithstanding that tools
that implement policy could rely on such data in making decisions. But that's qualitatively different from Jehan's proposal as I understand it. In particular, I don't envision that if such a mechanism were implemented in the spec and software, and used as
intended by the GIMP, that it would in fact satisfactorily resolve the issue that motivated the proposal.</div>
<div><br>
</div>
<blockquote style="margin-top:0;margin-bottom:0">
<div>In my experience, things like this haven't really come up, so I'm inclined to agree with you that it doesn't warrant changing the standard. But I think it's better to understand what's specifically going wrong and work out how else it can be improved,
rather than insisting that this could never be part of a desktop file. Labelling options with some kind of priority is compromise we live with in various places.<br>
</div>
</blockquote>
<div><br>
</div>
</div>
</div>
<div>I am all for understanding the problem and its context in order to find an appropriate solution. It is based on my present understanding of the context that I persist in asserting that desktop files should not express policy. I don't see anything in
the specific problem presented that challenges that position as far as I am concerned, and I am having trouble imagining what sort of thing would. In short: although firm, my position is analytical, not dogmatic.</div>
<div><br>
</div>
<div><br>
</div>
<div>John</div>
<div><br>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="2"><br>
Email Disclaimer: www.stjude.org/emaildisclaimer<br>
Consultation Disclaimer: www.stjude.org/consultationdisclaimer<br>
</font>
</body>
</html>