New `MimeType` fields in .desktop

Tue Feb 16 17:57:13 UTC 2021

Hi!

On Tue, Feb 16, 2021 at 5:55 PM Bollinger, John C <John.Bollinger at stjude.org>
wrote:

> 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.
>

I am a bit confused about what you are talking about. I am talking about
the .desktop file specification, hence I am obviously talking about Linux
distribution installation. We don't provide an "installer" or
"package-installation script" of any sort for Linux (well we have a
Flatpak, but I can ensure you we don't do what you say, because I wrote
most of this package manifest; and anyway Flatpak doesn't have this kind of
ability, it also only provides desktop files).
It looks to me like you are talking about our Windows installer, which is a
completely different topic (yes file association works differently on
Windows).

For GNU/Linux systems (and possibly *BSD?), as far as I know, the only
thing we provide (relatively to file format association) is the desktop
file where we list supported formats, as is the standard on such systems.
We don't have an installer and certainly no "automated installation
script", neither "dialog for selecting the image formats for which it
should be the default application"; so I have no idea what kind of clumsy
behavior of ours you mention.

Or maybe you are talking about some specific packaging scripts by
distribution packagers (are they really distribs which do what you say,
though?). Then this is exactly the problem I want to solve, packagers
cannot know and set up format association rules for every software out
there (Debian has more than 50,000 packages; same for Fedora, etc.).
Actually the Desktop or AppData specification got created exactly for this
reason: so that distribution don't have to manage themselves the things
that the software devs know the best (software title, description, icon,
mime type association, etc.).

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

First of all, I am talking about *default* behavior. This is why I even
said explicitly in my email:

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

So if one sets explicitly any other software as default handler of XCF
file, no of course, GIMP should not take over.

But if they don't, yes it is perfectly reasonable that after you installed
GIMP, the system sets it as being the default handler for XCF. Same as if
Photoshop was available on Linux, it should be the default for PSD files.
Sorry to say so, but saying it could be better otherwise is just silly.

Obviously for some people specific usage, you might want some different
association. Maybe some people want that a double-click on their XCF files
end up in another software and that's fine. That's why manual association
settings exist. But you cannot pretend this is the default expectation.

> 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.
>

I have a hard time understanding what you are trying to prove. You cannot
handle all possible cases, this is completely obvious. The computer is not
in people's head. So yeah there are no ideal work-for-all solution for
fully ambiguous case by nature.
Of course when several software are on the exact same field and support the
exact same formats, the system cannot choose for them.

I am talking about improving the hints based off knowledge of less
ambiguous cases (for formats which are exactly in the intent of a given
software).

Jehan

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

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