New `MimeType` fields in .desktop

[David Faure]

On lundi 3 mai 2021 13:47:17 CEST Eli Schwartz wrote:
> 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.

Wanna bet? It's my code, I know very well where it is :)

(But we in fact agree, see below. I should have prefixed my sentence with a 
"Yes,")

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

Link, no, indeed, but there are other ways to call code than linking: 
executing processes, for instance.

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

Exactly. And kde-open calls into KService. So for a Qt app in a KDE 
environment (Plasma workspace), my assessment is correct, the actual 
implementation that ends up being triggered is the one in KService.

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

Right.

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

OK. Then we're both right. I also chose my words very carefully by saying
"in the Qt/KDE world", i.e. when KDE is there into the equation.

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

I understand. But then, if
* the distro doesn't want to choose
* the user hasn't made any specific choice
* the application developers are not the best candidate for choosing
then who remains? :)

Actually in KDE we've had a historical solution which allowed application 
developers to set an "InitialPreference" number in the desktop file,
but this still requires a desktop-environment-wide agreement.
For instance it allowed us to say that for images, viewers should have
a higher default preference than image editors.
But looking at krita today I see a very high InitialPreference so I guess this 
didn't fully work out either...
Let's just say it worked as a a 4th level like:
* the desktop environment as a whole decides on ordering
But of course with apps coming from multiple DEs this can only lead to a fight 
between gimp and krita as to who should have the highest preference.

In the end I think 
1) desktop environments can provide a mimeapps-$desktop.lst for distros to use
2) users will still have to do some adjustments, especially when using distros 
who didn't want to decide for them.

The old debate of View vs Edit doesn't really solve this, as someone mentioned 
here, different apps have different features, which goes far beyond View or 
Edit.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5