<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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 11:35 AM, Jehan Pagès <jehan.marmottard@gmail.com> wrote:</div>
<blockquote style="margin-top:0;margin-bottom:0">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div>
<div dir="ltr">
<div>I didn't want to answer this email, but some parts are so wrong that I couldn't stop (<a href="https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxkcd.com%2F386%2F&data=04%7C01%7CJohn.Bollinger%40stjude.org%7Cdc900cd3897645a6f54a08d8d36a6c08%7C22340fa892264871b677d3b3e377af72%7C0%7C1%7C637491801341118585%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=M%2FQxRQNgs672Upnx%2FPMi6wlsIzI2NfSwuLjA8%2BPtEoo%3D&reserved=0" originalsrc="https://xkcd.com/386/" shash="mlRXNBOzetowAatWl/jitVMBlb7dfYGrOcYYw+VjWv9drTE2jevG+Kip1NBNiCwh1ZTTnjxnDqo6PD44w0EiySSJq4Z/QckHg4/r70CKhNhGaZWeGsN/7qzwDO3vKCkDw6HUa1nb5uoDQWY/qJGGLJ9EOZYQfEnARTE0NhqYUWI=">https://xkcd.com/386/</a>
🤣).</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Ah, one of my favorites.</div>
<div><br>
</div>
<blockquote style="margin-top:0;margin-bottom:0">
<div>
<div dir="ltr">
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Wed, Feb 17, 2021 at 4:13 PM Bollinger, John C <<a href="mailto:John.Bollinger@stjude.org">John.Bollinger@stjude.org</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
On Wednesday, February 17, 2021 6:30 AM, Thomas Kluyver <<a href="mailto:thomas@kluyver.me.uk" target="_blank">thomas@kluyver.me.uk</a>> wrote:
<blockquote style="border-color:rgb(200,200,200); border-left:3px solid rgb(200,200,200); padding-left:1ex; margin-left:0.8ex; color:rgb(102,102,102)">
<div>Distinguishing things like 'native' and 'equivalent intent' filetypes seems tempting, but I suspect it would end up with a lot of awkward grey areas. If this is a problem worth solving, I'd be more inclined to make a numeric priority scale, something like
the shared-mime-info database uses for assigning mimetypes to files (which allows e.g. ODT files to be recognised as ODT rather than general zip files).</div>
<div><br>
</div>
</blockquote>
<div>The problem here is that the application to be used to open files of a particular type is not an inherent characteristic of the file type</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Maybe not all formats, but for most, of course it is.</div>
</div>
</div>
</div>
</blockquote>
<div>
<div dir="ltr">
<div class="x_gmail_quote">
<div><br>
</div>
<div>"Maybe not for all formats" establishes my point. There are definitely file types, including many of the most commonly used ones, that can reasonably be opened by many different applications. Therefore, the application to be used to open a file is not
a property of file types. That some specific file types have unique distinctive choices of application could be construed as a property of those specific file types, but not as a property of file types in general.</div>
<div><br>
</div>
<div>But even in the "unique distinctive choice" case, I do not construe the unique choice as a property even of the specific file type, but instead a property of the universe of software. It may be that under the present circumstances there happens to be
only one program that's a natural choice, but there could be others at some point. For example, suppose I prepare and distribute my own full-featured image editing software, and I choose to have it use XCF as its native format. Suppose I expend the resources
to produce feature parity with the GIMP. Now, there isn't a clear choice of which application is best to use for opening XCF files on a system that has both programs. But nothing about the file type itself is different, so the once-unique choice of application
must never have been a property of the file type in the first place.</div>
<div><br>
</div>
</div>
</div>
</div>
<blockquote style="margin-top:0;margin-bottom:0">
<div>
<div dir="ltr">
<div><span style="color: rgb(0, 0, 0); font-size: 14px;"> </span><span style="color: rgb(0, 0, 0); font-size: 14px;">If you have a XCF or PSD file, of course it is a work file.</span><br>
</div>
<div class="x_gmail_quote">
<div> You could just want to display it, but that's the exception. When you want an image for display, you will usually export it to a display image format (JPEG, PNG, WebP, AVIF… whatever is out there these days).</div>
<div>[...]</div>
<div>Saying the application (or types of application) is not an inherent characteristic of the file type is really wrong for most file formats out there (there are some exceptions of course).</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<div dir="ltr">
<div class="x_gmail_quote">
<div>In the more general and more category-oriented sense I was speaking, I am quite right. And we're talking about a general-purpose facility, so that's the direction we should be looking. XDG is well factored in this sense: it has a mechanism for tracking
and identifying file types; it has a mechanism for tracking and describing the properties of applications; and it has a mechanism for managing associating files with applications by file type and assigning default applications. This modularization creates
an appropriate separation of interests and minimizes unneeded data dependencies, and it is easy to manage from a policy perspective, because all the policy control is in one place instead of spread over many files. It is a good design. That does not mean
it cannot be improved, but improvements should harmonize with the existing design elements.</div>
</div>
</div>
</div>
<blockquote style="margin-top:0;margin-bottom:0">
<div>
<div dir="ltr">
<div class="x_gmail_quote">
<div><br>
</div>
<div> Most formats definitely have intents associated with them. There are formats for editing, formats for streaming/speed viewing, formats for quality viewing, and so on.</div>
</div>
</div>
</div>
</blockquote>
<div>
<div dir="ltr">
<div><br>
</div>
<div>Intent is not software application, as my GIMP-clone example demonstrates.</div>
</div>
</div>
<blockquote style="margin-top:0;margin-bottom:0">
<div dir="ltr">
<div class="x_gmail_quote">
<div><br>
</div>
<div>People having an issue and answering them that they are "mischaracterizing the problem" is one of the worst responses possible. Basically "don't fix the software, fix the user"?<br>
</div>
</div>
</div>
</blockquote>
<div dir="ltr">
<div class="x_gmail_quote">
<div><br>
</div>
<div>Who said that's how you should respond to people who raise issues? Certainly not me. That they have mischaracterized the problem is information useful to
<i>you</i> in identifying the most appropriate solutions. To the user you say, "Here's how to fix it" or even "Here's a tool that will fix it for you." You might even add "We're working on it" if you can do so in good faith.</div>
</div>
</div>
<blockquote style="margin-top:0;margin-bottom:0">
<div dir="ltr">
<div class="x_gmail_quote">
<div><br>
</div>
<div>In particular when here the issue is very visible. The desktop format is much too broad as to what consists of a MIME type support. It is obvious no desktop out there will be able to make reasonable default choices with such basic information.</div>
</div>
</div>
</blockquote>
<div dir="ltr">
<div class="x_gmail_quote">
<div><br>
</div>
<div>Just as I would be open, in principle, to adding some variety of quality of support measure to the mime-association information in desktop files, I would also be open, in principle, to adding some kind of purpose-based categorization of MIME associations.
The two might even work together. but I don't see any of that in the proposal that was brought to the table. I never denied that there was an issue, but I did and do challenge the specific proposal, and I furthermore question to what extent individual software
packages are positioned to provide good solution, whatever changes might be made in the desktop file specification.</div>
</div>
</div>
<div dir="ltr">
<div class="x_gmail_quote">
<div><br>
</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>John</div>
<div><br>
</div>
</div>
</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>