New `MimeType` fields in .desktop

Wed Feb 17 17:35:17 UTC 2021

Hi!

I didn't want to answer this email, but some parts are so wrong that I
couldn't stop (https://xkcd.com/386/ 🤣).

On Wed, Feb 17, 2021 at 4:13 PM Bollinger, John C <John.Bollinger at stjude.org>
wrote:

> On Wednesday, February 17, 2021 6:30 AM, Thomas Kluyver <
> 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. 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).
Of course, you can edit from a JPEG/PNG and many people do (me included).
It's completely fine to do this (which is why it is in the open list) but
it's not what these files are made for (they are lossy, yes even PNG is
hugely lossy compared to a work file; they have countless limitations,
etc.). These are final output files not work files, often not even good
source files (pro photographers try not to start from JPEG, they start from
the RAW files).

If you send someone a text for viewing, it could be a PDF for instance. You
send the ODT or OOXML when you want them to edit it. Sure many people just
send ODT/OOXML, and sure you can edit PDF. But that's not the intent.
Same as you send someone a generated PDF, not a LaTeX file, by the way.

If you send someone a .blend file, it's to open in Blender (or maybe
another 3D software which supports importing from Blender format), not to
view the 3D object or the edited scene. If you want to just show a video to
someone, you render a .mov/avi/mp4 or whatever other end-formats.

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). 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. Moreover
even within a given broad intent, you get more specialized sub-category
formats (if you take video formats for viewing for instance, there are so
many formats specialized in some specific fields). Most formats are usually
even created to fill in a specific intent and sometimes specific
applications are created to specialize in the given intent.

> , nor of the set of available applications that can handle that type.
> That's why the user has no good reason to expect stability of default
> application where no specific one is configured.  And it's also why the
> user is mischaracterizing the problem if they claim that the GIMP has taken
> over file associations for a given file type -- installing a desktop file
> simply does not do that, because desktop files express no policy.
>

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

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.

I never thought much so far (until we got a recent report about it), but I
do recall I had similar issues by the past. I remembered times when opening
.txt. file would open them in LibreOffice and I had to fix it manually. I
remembered times when some software native format ended up opened by
another application whose native format was another and which didn't even
have a complete support of the other format. And so on.

So no, the user did not mischaracterize anything when one thought that
there was a problem. The computer cannot be in the person's head to handle
special cases, but we can definitely improve the default situation, because
yes both application formats definitely have intent built-in within
themselves.

Jehan

Another approach to the stability issue (e.g. GIMP 'taking over' the JPEG
> mimetype) is for the desktop to fix it: if you open a JPEG file and there
> isn't already a default application for that, store whatever it uses as the
> default application, so it won't change unless the user manually changes
> the association or uninstalls that application. I think that could be done
> without changing any specs.
>
> Yes.  This would be a manifestation of "better tools" such as I suggested
> above.  It would be an appropriate way to address the issue from the XDG
> side.
>
>
> John
>
>
> ------------------------------
> *From:* xdg <xdg-bounces at lists.freedesktop.org> on behalf of Thomas
> Kluyver <thomas at kluyver.me.uk>
> *Sent:* Wednesday, February 17, 2021 6:30 AM
> *To:* xdg <xdg at lists.freedesktop.org>
> *Subject:* Re: New `MimeType` fields in .desktop
>
> Caution: External Sender. Do not open unless you know the content is safe.
>
> On Tue, 16 Feb 2021, at 23:04, Bollinger, John C wrote:
>
> But that does not imply that some applications should be able to claim to
> be more equal than others with respect to particular file types.
>
>
> I think Jehan's idea is that applications should be able to claim to be
> *less* equal than others for a given mimetype, i.e. that GIMP could declare
> 'I can open JPEGs, but you should probably use something else by default'.
> Obviously, if the user explicitly set GIMP as the default handler for
> image/jpeg, it would override this priority.
>
> 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).
>
> Another approach to the stability issue (e.g. GIMP 'taking over' the JPEG
> mimetype) is for the desktop to fix it: if you open a JPEG file and there
> isn't already a default application for that, store whatever it uses as the
> default application, so it won't change unless the user manually changes
> the association or uninstalls that application. I think that could be done
> without changing any specs.
>
> Thomas
>
> ------------------------------
>
> Email Disclaimer: www.stjude.org/emaildisclaimer
> Consultation Disclaimer: www.stjude.org/consultationdisclaimer
> _______________________________________________
> 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/20210217/44c446c6/attachment-0001.htm>