New `MimeType` fields in .desktop

[Bollinger, John C]

On Wednesday, February 17, 2021 11:35 AM, Jehan Pagès <jehan.marmottard at gmail.com> wrote:

I didn't want to answer this email, but some parts are so wrong that I couldn't stop (https://xkcd.com/386/<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> 🤣).

Ah, one of my favorites.

On Wed, Feb 17, 2021 at 4:13 PM Bollinger, John C <John.Bollinger at stjude.org<mailto:John.Bollinger at stjude.org>> wrote:
On Wednesday, February 17, 2021 6:30 AM, Thomas Kluyver <thomas at kluyver.me.uk<mailto:thomas at kluyver.me.uk>> wrote:
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).

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

Maybe not all formats, but for most, of course it is.

"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.

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.

 If you have a XCF or PSD file, of course it is a work file.
 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).
[...]
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).

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.

 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.

Intent is not software application, as my GIMP-clone example demonstrates.

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"?

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 you​ 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.

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.

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.


Regards,

John


________________________________

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20210217/8bca342b/attachment.htm>