New `MimeType` fields in .desktop

Thu Feb 18 15:51:49 UTC 2021

Hi Charles,

On Thu, Feb 18, 2021 at 4:00 PM Charles Plessy <
charles-listes+xdg at plessy.org> wrote:

> Le Tue, Feb 16, 2021 at 05:11:36PM +0100, Jehan Pagès a écrit :
> >
> > Hello all!
>
> Hello Jehan and everybody!
>
> > 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.
>
> In Debian we are automatically translating Desktop entry files to
> Mailcap entry files, and we hit a similar problem: suddenly the Mailcap
> users would open PDF documents with GIMP by default…
>
> http://charles.plessy.org/Debian/debi%C3%A2neries/pdf/index.en.html
>
> A change of the Desktop entry specification going in the direction you
> propose would allow us to give lower Mailcap priorities to programs
> declaring that they do not aim at being the default for a given media
> type.
>
> > 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:
> >
> > - IntentMimeType: the list of supported mime types which can be
> considered
> > of the same nature as the native mime types, the same "intent" files.
>
> One downside with this approach is that if you update GIMP's Desktop
> entry file and it is read by a program that is not supporting the
> proposed new version of the specification, the most important media
> types might be ignored.
>

I thought about it too, and this is why I was proposing the NativeMimeType
and IntentMimeType as additional, not replacement (but it must have been
lost in the many emails). In particular, it means that XCF MIME types will
be both in the historical MimeType and the new NativeMimeType fields.

Same PSD or ORA would be both in MimeType and IntentMimeType.

This way, the problem you raise will simply not happen because a program
which only supports the old format of the spec will still see XCF, PSD and
ORA in the MimeType list.

Instead, how about having a new field (for instance ExtraMimeType) for
> indicating the lower-priority media types.  Then software like GIMP
> could "demote" them in the new field, and at worse if the new field is
> not parsed, then the native or intended types will still be recognised.
>

If we do this, we change the meaning of MimeType field for these programs
and we actually create the problem you mentioned for the other
(out-of-intent) formats. Indeed we usually don't want GIMP to be the
default for PNG, JPEG, PDF or SVG. Usually we have a much better default
for all of these.

But sometimes when there is absolutely no other software handling these
formats, GIMP still is a nice fallback (better than nothing). This happens
for very old formats for instance (GIMP still has support of some very
old/weird formats and we don't intend to get rid of these supports), which
no image viewer care to support nowadays.
It also happens for some very specialized formats (used in specialized
fields like some video game image formats).
And finally it happens with very recent formats. For a while for instance,
I believe the only software in Linux able to show WebP images was GIMP (now
also at least on Firefox and Chrome|ium). Right now, I think AVIF images
might only be viewable in Chrome|ium and GIMP. As for HEIC images, I still
haven't found any other software on Linux, but GIMP of course, to display
them.

So even though all these MIME types are not GIMP primary intent, it's still
nice that programs supporting the old desktop spec only would know that
GIMP can at least serve as a suitable fallback.

In other words, my proposition does not change at all the meaning of the
"MimeType" field (still means "this software can 'open' these MIME types"
with "open" being a broad range of meaning), but it adds 2 semantic fields
meaning "what we are really meant to do is editing image projects with
these formats".

Last but not least, if we go with your idea, the MimeType field becomes a
de-facto NativeMimeType field and would therefore always get top priority.
Say now that an image viewer gets XCF, PSD and ORA display support (which
is a fine feature to have). Then it would add it in its MimeType which
could override the MimeType of GIMP. And now when you click these work
images, your viewer is run instead of your specialized work program.
On the other hand, when I make the Native|IntentMimeType fields something
special of their own, we explicitly say "yeah these are particular", and
when any program has such fields, these take priority over normal MimeType.

Basically MimeType still is the normal field and most programs would have
nothing to change. An image viewer should not move all images mime types it
supports into Native|IntentMimeType. These fields will be used only for
specialized software.

Does it make sense? 🙂

Therefore: a desktop parsing program doesn't support the old spec and/or a
given program devs haven't updated the .desktop file? No prob, it works
like before. The desktop parsing program supports the new spec and a given
program devs added the 2 fields? You get nicer additional hints to get
slightly better default file association.

Jehan

> Have a nice day,
>
> Charles, maintainer of the mailcap and media-types packages in Debian.
>
> --
> Charles Plessy                         Nagahama, Yomitan, Okinawa, Japan
> Tooting from work,           https://mastodon.technology/@charles_plessy
> Tooting from home,                 https://framapiaf.org/@charles_plessy
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
>

-- 
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/20210218/ba309680/attachment.htm>