New `MimeType` fields in .desktop

Wed Feb 17 16:42:01 UTC 2021

Hi!

On Wed, Feb 17, 2021 at 1:30 PM Thomas Kluyver <thomas at kluyver.me.uk> wrote:

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

Yes! Finally someone who reads emails before answering. :-)

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

It's an interesting idea, but wouldn't it be very hard to tell? Like if
someone asked me how much of PSD is supported on GIMP (on a scale, say from
0 to 10), I would have no idea where we stand. We do have support, and we
try to improve it regularly. We also accept patches with arms wide open.
But how much of it is supported? No idea.
And I'm pretty sure that unless some type were your native format (either
because you created it, or decided to make it your own native format too),
most applications out there would not be able to say exactly where they are
on a scale, since their focus is elsewhere (creating the best application
supported by its own format). This means that what most devs would set for
their support of many formats would be very approximate. Thus if it's later
used to determine which should be the best defaults, it would not be
actually fair.

What we can say is that PSD is a format with a somewhat similar intent
(raster image editing work-in-progress format) and that we have some ok
support of it.

The other risky issue of comparing support with a scale is that some
software may actually have a not-perfect support yet still be completely
intended for a format. Typically if not mistaken, LibreOffice, OpenOffice,
Calligra all have OpenDocument as their native formats. Yet maybe one of
them misses the support of specific features (I have no idea if true, but
would not be impossible). Therefore say this one application sets a support
at 9 whereas the other would have support at 10. It would not be fair
because their intent matters most here IMO. If they all intend to support
ODT as native format, it is very likely that if someone installs any of
them, they are still fit as good default ODT editor.

This is the reason why I went with semantic fields rather than scale-based
fields. I think that intent matters most here. "What is your program
actually for?"

Nevertheless if we wanted to have some types of scaling (I would say,
additionally to the intent-based semantics), I would go for
approximate/named ones, not numeric based for the reasons cited above. Like
"Perfect" (you can open any file), "Very Good", "Good", "Average" and so
on. Then we could probably situate GIMP's PSD support there (and even so,
not so sure, I'd hesitate between Average and Good nowadays; even this, it
depends on people anyway; for many usage, our support is good, but for
people needing specific features which GIMP doesn't provide, they would
consider our PSD support as bad. As I said, situating non-native support on
a scale is a lot more difficult that one would imagine).

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

Yeah the default application on same level of intent is a difficult
question, which was why I was not really focusing on it. I'm not sure but
it doesn't look like all distributions/desktop do the same thing currently.
It would seem that some at least would just set the last installed software
as default. This is definitely wrong often, but I can see also how it can
make sense to some. I don't actually think there is a single right answer
to this problem unfortunately.

IMO adding some semantics on the file association intent is a good
compromise (hence my proposal), but we may not have better hints than
these. You may have several applications installed with the same native
format. Then which should be the default? Impossible to answer (only the
user can). You may have no application using a given format as native, but
several applications with similar intent and supporting it, which should be
used? And finally you may have no application with native or intent, but
several applications with support, which should be used? All these
questions cannot really be answered IMO.

With this in mind, it might not be necessary to update the specs with
stability advices. Or if we do, it would only be to make an arbitrary
choice for the sole purpose of having at least a common behavior across
distributions and desktops (which is nice too) but I don't think we can
actually say for sure this is a better choice. I can definitely see pros
and cons to both logics (keeping stability or not when no user-set
preferences were set).

Jehan

> Thomas
> _______________________________________________
> 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/210f2b55/attachment-0001.htm>