New `MimeType` fields in .desktop

Tue Feb 16 16:55:09 UTC 2021

Hello all,

I think the decision to omit MIME-type priority is about scope, not about concerns regarding specific (mis)uses.  Desktop files can express that an application is _suitable_ for handling files of certain types, but it is not their role to convey system policy, such as which application actually should handle any particular file.

With regard to the GIMP example, then, I do not see a missing feature of the desktop entry, but instead clumsy behavior of the GIMP installer -- probably as used by an automated package-installation script, for I think I recall that a manual installation of the GIMP provides a conventional dialog for selecting the image formats for which it should be the default application.

Moreover, I don't think that splitting the supported MIME types into two tiers would really solve the underlying problem.  It would give hints to installers and management software that they don't get now, but who's to say, for example, that just because XCF is its native format, GIMP ought to take over from some other application as the default handler for that type?  And what if multiple applications have some of the same native types?  (Consider text editors, for example.)  Hints notwithstanding, it's still a policy and system management question that desktop files are not well positioned to address.

Regards,

John

--
John C. Bollinger, RHCSA

________________________________
From: xdg <xdg-bounces at lists.freedesktop.org> on behalf of Jehan Pagès <jehan.marmottard at gmail.com>
Sent: Tuesday, February 16, 2021 10:11 AM
To: xdg <xdg at lists.freedesktop.org>
Subject: New `MimeType` fields in .desktop

Caution: External Sender. Do not open unless you know the content is safe.

Hello all!

I would have a small proposition about the mime type handling in desktop spec.
I perfectly understand why the format does not specify any priority whatsoever so far (some software might want to put themselves priority for everything).

> There should be no priority for MIME Types in this field, or any form of priority in the desktop file. Priority for applications is handled external to the .desktop files. [from Desktop Entry Specification ]

Yet I believe that some trust is also needed if we want better format-software associations' default behavior. Actually I would be interested in some priority-related fields for the exact opposite as what the spec is scared of: responsible devs will be able to tell (through their desktop file) when a software should not overload existing mimetype priority settings. In my case, I would do this for GIMP.

Typically someone reported an issue about GIMP taking over handling of image types it supports every time it is installed/updated. So for instance JPEG images were not displayed by default with a simple image viewer anymore, but in GIMP.

When it is perfectly reasonable for its native image format (XCF), and possibly for other similar format when another software hasn't set it as its native format (typically PSD or ORA, you usually want to edit them not just show them, so if you don't have say Photoshop, you'd look for software with similar intent, such as GIMP), it is obviously not ideal for common finale image formats (JPEG, PNG, etc.) which you'd want to see in a viewer.

I do remember having had similar issues over the years for various format associations with various software, forcing me to override settings manually after. Worst case I encountered was when some software would even take over handling the native format of another software (even though this other software is installed as well)!

It's still important that GIMP can advertize supporting all these formats, for instance to be proposed in the recommended alternative list of software (for when you want to edit the image files); or also when no other software support them (many old image formats and often some very recent image formats are nearly only supported by GIMP among Free Software), GIMP can serve as nice display fallback. Yet it'd be nice if we could make a difference.

So I would propose 2 fields with the same syntax as MimeType field:

- NativeMimeType: the list of mime types which can be considered as the native formats of the software. For instance for GIMP:

NativeMimeType=image/x-xcf;image/x-compressed-xcf

- IntentMimeType: the list of supported mime types which can be considered of the same nature as the native mime types, the same "intent" files. Typically GIMP is an editing software, and XCF is an image edition project file. Same are the OpenRaster format (standard exchange format for such programs) or native formats of other similar software (e.g. PSD from Photoshop). So GIMP could have:

IntentMimeType=image/x-psd;image/openraster

To keep compatibility with older systems, all these formats should **also** be in the MimeType field.

What it means for a system/distribution when you install/update a software with a NativeMimeType field: the new software **should** become the new default association.

For IntentMimeType, more software are expected to have these. NativeMimeType is obviously a stronger association.

As for MimeType, unless a software happens to be the only one handling a given format (hence it's an ok fallback), the system should probably never switch the defaults.

Of course, if a format-software association was set manually, it would be best to never let automatic re-association with another software happen.

What do you think?

Thanks!

Jehan

--
ZeMarmot open animation film
http://film.zemarmot.net<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffilm.zemarmot.net%2F&data=04%7C01%7CJohn.Bollinger%40stjude.org%7C55519cf84c104ee366c708d8d2959445%7C22340fa892264871b677d3b3e377af72%7C0%7C1%7C637490887166222524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UH3FW5BH7JPQqwaMHxaqK9dZtK4uIoXJ9R37tLvC0bg%3D&reserved=0>
Liberapay: https://liberapay.com/ZeMarmot/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fliberapay.com%2FZeMarmot%2F&data=04%7C01%7CJohn.Bollinger%40stjude.org%7C55519cf84c104ee366c708d8d2959445%7C22340fa892264871b677d3b3e377af72%7C0%7C1%7C637490887166227503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uBpm1Ye%2FPOxFpJoZR8DNsCfTnuGjdRquv4bF779aP0w%3D&reserved=0>
Patreon: https://patreon.com/zemarmot<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatreon.com%2Fzemarmot&data=04%7C01%7CJohn.Bollinger%40stjude.org%7C55519cf84c104ee366c708d8d2959445%7C22340fa892264871b677d3b3e377af72%7C0%7C1%7C637490887166232480%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ISzJiMR5FBBYg0ZRRQ2gDkhchffddN2uj0XxNPODyCw%3D&reserved=0>
Tipeee: https://www.tipeee.com/zemarmot<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.tipeee.com%2Fzemarmot&data=04%7C01%7CJohn.Bollinger%40stjude.org%7C55519cf84c104ee366c708d8d2959445%7C22340fa892264871b677d3b3e377af72%7C0%7C1%7C637490887166237469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PDxkTqsDFK6bQp8fUO2ObZsDIZ0dVP6WurMfw%2F0LuMA%3D&reserved=0>

________________________________

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/20210216/f5211452/attachment-0001.htm>