New `MimeType` fields in .desktop

[Jehan Pagès]

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
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20210216/8bb5cb89/attachment.htm>