New `MimeType` fields in .desktop

[Eli Schwartz]

On 5/3/21 5:58 AM, David Faure wrote:
> On jeudi 18 février 2021 03:17:45 CEST Eli Schwartz wrote:
>> On 2/17/21 5:52 PM, Bastien Nocera wrote:
>>> 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. GLib probably behaves differently than Qt does,
>>> which means that the file managers using either of those are likely to
>>> behave differently.
>>
>> Qt's native support for opening files in accordance with XDG is to
>> invoke /usr/bin/xdg-open.
> 
> The actual code for choosing preferred applications for a mimetype, in the Qt/
> KDE world, isn't in Qt, but in KDE Frameworks (KService).

That seems highly unlikely. The Qt world can't possibly depend on the
KDE world, because KDE builds on Qt rather than Qt building on KDE. So
applications using Qt for cross-platform application programming, which
aren't KDE applications, will not suddenly go link in KService.

In fact, like I said immediately above, Qt's native facility here is
QDesktopServices::openUrl() which invokes xdg-open. xdg-open then checks
various things to probe for your currently running DE, and...

If that DE is some version of kde it will run kde-open or kfmclient.

If that DE is gnome, then "the Qt world" will be running a program that
then runs "gio open", and hence the actual code for choosing preferred
applications in the Qt world isn't in Qt, but in GLib.

I chose my words very carefully in response to "GLib probably behaves
differently than Qt does" by pointing out that Qt in fact does nothing,
but I assumed people know that xdg-open defers to GLib if you're logged
into gnome, and defers to KDE frameworks if you're logged into KDE.

> I'm late to this thread, but before we talk about adding even more complexity 
> to the solution of choosing an app for a mimetype, I'd like to understand why 
> https://specifications.freedesktop.org/mime-apps-spec/latest/
> doesn't solve the issue. If the distro's mimeapps.lst says
> image/jpeg=gwenview.desktop;gimp.desktop;
> then JPEG files will be opened in gwenview (if installed) rather than in GIMP,

I mentioned this earlier in the thread, repeating here:

> The workaround is for:
> - a DE to define preferred default handlers in $DE-mimeapps.list
> - an OS to define preferred default handlers in mimeapps.list
> 
> The former is, well, kind of a solution, you can at least solve the
> inode/directory problem by force-associating the DE's native file
> browser for this one mimetype. You can also solve it for any flagship
> applications shipped by the DE, though that's more iffy because maybe
> people don't install the flagship programs.
> 
> The latter is only a solution for e.g. Ubuntu, where a carefully curated
> selection of flagship applications shipped by the *OS* instead of the
> DE, are present. You thereby attain a specific look and feel intended by
> the Ubuntu desktop team, and consistently get pointed to their preferred
> application.
> 
> None of this scales well, at all, especially not for mimetypes that are
> even slightly off the beaten path.


Yes, I'm on the packaging team for a Linux distro that declines to be
put in the position of being an arbiter of good taste. Don't look to us
to choose preferred mimeapps.lst applications, we refuse.

Even if we wanted to do it, we would be required to provide a
mimeapps.lst defining preferences for several dozens of applications per
mimetype, and any time a hundred different people add a new program to
the repositories we'd need to update this list, and then at the end of
the day users are going to have GIMP plus an unofficial user package
(the "AUR" / Arch User Repository) and GIMP is still going to be the
first on the list somehow for these last-resort-only mimetypes, and the
complaints will be fewer but never actually go away.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20210503/6e413e4a/attachment.sig>