New `MimeType` fields in .desktop

[Jehan Pagès]

Hi!

On Wed, Feb 17, 2021 at 11:52 PM Bastien Nocera <hadess at hadess.net> wrote:

> On Wed, 2021-02-17 at 22:07 +0100, Jehan Pagès wrote:
> > <snip>
> > There is also something which I am not fond of with the order
> > depending on a shared database: we must agree on an order which might
> > not be fair. Say 2 applications are on the exact same action fields,
> > i.e. they both work on the same file formats (for instance JPEG, PNG
> > for image viewers). If the defaults depend on this shared database,
> > then the same one will consistently be the default image viewer
> > shadowing (if installed) all the others. Be it based on character
> > order (then you'd want to just name your app "aaa") or just whatever
> > the database maintainer prefer for oneself, it's not right.
>
> It's not a database, it's a default configuration for various desktops.
> As mentioned in my previous email, it's also likely to be easily
> changed in the "default applications" panel in GNOME, and equivalent
> somewhere else.
>
> > On the other hand, when no order is specified centrally, but each
> > software is able to tell its intent "I'm made to display JPEG, PNG…"
> > without specifying priority relatively to other software, at least we
> > can go with fairer algorithm (something not based on an arbitrary
> > choice making a strict order). Be it "last installed" or "keeping
> > stability to whatever was here first" (then it will likely be
> > dependent on your desktop choice during install, and distrib
> > maintainers, at least not the same on all distributions).
>
> The order for mime-types with no defaults has nothing to do with a
> "shared database", it's implementation specific, as it's not codified
> in the mime specs.


I know. Your quote of mine was me discussing the idea of getting more
logics into a shared database as proposed earlier by Thomas (clearly
looking at the part of I quoted myself doesn't say much of it, it was in
the flow of the discussion). But I'm aware it's not like this currently. I
was only preemptively saying that I'm not fan of this proposed solution to
the problem.


> GLib probably behaves differently than Qt does,
> which means that the file managers using either of those are likely to
> behave differently.
>
> If you want to solve this problem, you'll probably need to figure out
> whether their behaviour is intentional, and then change the specs to
> clarify the intended behaviour.
>

How do we know this? Who will know this if not even you who maintain these
files know this? I think we are all aware that with software going on for
dozens of years, sometimes some of the reasons for things get lost in time.
🙂
Now even if it's intentional, I don't think that's such a good behavior
anyway. So I'm not sure it matters too much to know if it is actually
intentional or not.

Which is why I proposed the change from my first email. So far, with all
the discussions which went on, I still believe it is a good solution,
mostly because it scales well. Developers just have to add a bit more of
semantic associations in their desktop file. And then distributions/desktop
can update their no-default algorithm to use this info if it is present.

In particular, a software which set some native and intent MIME types
explicitly says that it is likely not a proper default application for all
the other MIME types it supports (e.g. GIMP is not a proper default for
JPEG handling, neither is LibreOffice the best default for .txt files…).
Oppositely it explicitly says it is a very good fit for whatever is its
native formats, and that it's an appropriate fallback for same-intent
formats if no applications set it as native.

The nice thing is that it requires really not so much change from everyone
and it looks to me it would work quite well here.

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/195d9881/attachment.htm>