New `MimeType` fields in .desktop

[Jehan Pagès]

Hi!

On Thu, Feb 18, 2021 at 9:46 AM Bastien Nocera <hadess at hadess.net> wrote:

> On Thu, 2021-02-18 at 02:36 +0100, Jehan Pagès wrote:
> <snip>
> > How do we know this? Who will know this if not even you who maintain
> > these files know this?
>
> What files do I maintain? I don't maintain shared-mime-info anymore, I
> maintain a single xdg spec, not the mime or desktop ones, and I don't
> maintain the implementation in Qt or GLib.
>

Yes sorry, once again, I was not clear. I was referring to the fact you
said you used to maintain a XDG spec, and apparently the GNOME defaults
settings. Now even these facts, maybe I don't have them clear, but that
illustrates my point that I am not convinced that a solution to the current
problem will lie in a common configuration again (per desktop? Per
distribution? Per distribution-desktop couple? Even this is not clear as
showed a few emails saying contradictory things on what this or that
distribution is now doing… or not?! A bit of a mess…), because it's just
hard to know where to address fixes and as a consequence, most software
developers just won't. So in the end, the list will stay maintained by a
handful of people at most and will only contain a few dozen entries.

Now with the proposed changes, there are 2 cases:

1. Either you don't really have a concept of native format, you just open a
variety of formats. Then you don't have to change anything. By having only
a MimeType field, this is what you say to the world: "yeah I can open all
these files indistinctively"
**So for instance image viewer won't have to change their desktop files.**
They just have many files that they can display. Maybe some even can
display XCF, then they will add it to their list.
**Text editors as well won't have to change their desktop files.**
They can just open any text-like formats and don't have a concept of native
format.

2. Now you have a concept of native format because your software is a bit
more specialized than just "display" or "use" random files. Then you can
add a NativeMimeType field. For such specialized software, there are also
usually other software (or standard formats) doing a similar thing and with
their own native formats and maybe your program is able to import it. It's
not your native format, support may be more lacking at times. You add these
in an IntentMimeType field, telling the world that you are able to handle
these files which are made by software of similar intent to yours. So if
you don't have the right software supporting this mime type as a native
format, all the software with this MIME type as IntentMimeType would have
precedence.

So for some example:

* GIMP would set XCF (and variants) as its NativeMimeType and PSD, ORA, PSP
(and other similar formats for raster editing) as IntentMimeType. Thus
saying that "XCF" is what they do best (and a XCF file was likely even
created by GIMP or by another software to be exchanged with someone on
GIMP), so GIMP is a very suitable default. The intent formats are not
GIMP's ones, but if you have no application out there with a suitable
NativeMimeType, then GIMP can be considered a fallback.
On the other hand, if you try to open a JPEG or PNG, software with these in
a generic MimeType (without NativeMimeType nor IntentMimeType) would get
precedence.
* LibreOffice Writer, OpenOffice or Calligra would set ODT as its
NativeMimeType and DOC or OOXML as IntentMimeType. TXT or the like would
not get redirected to LibreOffice anymore because you recently installed it
or whatever.
* Abiword on the other hand would set ABW as its NativeMimeType and ODT,
DOC or OOXML as IntentMimeType.
* Blender would have BLEND files as NativeMimeType and could add various
formats such as 3DS files on IntentMimeType (if it is able to "open" it
from command line as it would a .blend file, I am not sure, I never tried).

And so on.

Note that if a user set a custom default (explicitly), none of these
matters.

Why I think it's a good proposal:
1. Many software won't have to change their desktop file. If you are not in
an usage area with a concept of specialized formats or the like, you are
probably already good.
2. The software which should update their desktop file, it's not a huge
problem if they don't immediately. It will be neither worse nor better than
now. And when they update, it's just 2 fields to add.
3. It is just 2 added fields which can be ignored if used on a
desktop/distribution which has not updated its scripts for processing
desktop files. No breakage either. Then when they update their order
algorithm, it's not a huge code change, it's quite a simple one.

In other words, the transition will be smooth.

Note also that I am not against any other solution, since I read some were
not sure my proposal was the best even though a problem is acknowledged.
Maybe it's not, though I haven't thought of any better yet and was not
convinced by other ideas so far. But I am happy if anyone comes with some
better idea which would supersede mine. Until then, I stick with
argumenting my original idea. 🙂

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