New `MimeType` fields in .desktop

Mon May 3 18:39:32 UTC 2021

On 3 May 2021 7:06:05 pm GMT+05:30, "Jehan Pagès" <jehan.marmottard at gmail.com> wrote:
>Hi!
>
>On Mon, May 3, 2021 at 2:40 PM David Faure <faure at kde.org> wrote:
>
>> 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.
>>
>
>Which is why my original proposal is not about View vs Edit (please read
>it, as apparently you have not). It is about the intent of the app. If I
>take GIMP's intent, it is really about editing XCF files.
>
>Now if we comes into PSD or ORA files, these are not GIMP's native files,
>but they have clearly similar intent and since we support it, yes GIMP is a
>very sane choice too (but if Photoshop were on Linux for instance, I would
>say it should advertize to be about editing PSD, hence take precedence when
>installed).
>
>Finally we can open various end-formats (PNG, JPEG, WebM, and a few dozens
>more…) so GIMP advertizes it in its desktop file. It's important because it
>allows GIMP to be in the proposed secondary software (commonly right-click
>menu item "open with") which makes life easier to people; and also because
>in worst case when no other software can view some image format, even if
>you don't want to edit it, at least you can view it in GIMP as a fallback
>(I cited a few cases where we were the only free software able to display
>some formats for years AFAIK and even now there are some formats where it
>is still the case, it would seem).
>
>This is not a GIMP-only situation. I remember cases in my experience where
>LibreOffice would open .txt files (like what?!) and other similar weird
>events. Right now, we are in this situation where the default is regularly
>just weird and there have been various reports of this for years.
>
>So my proposition is not about View vs Edit, please read it. It is an
>intent concept, the intent is not too accurate on purpose, because at some
>point, over-precision doesn't make sense. Yes at some point the user will
>have to choose. For instance the format `.odt` is a valid native format for
>LibreOffice, OpenOffice and Calligra AFAIK, so if you have all 3 installed,
>the default could be any of these (until an explicit user decision). No
>need to add more accuracy IMO. But this much accuracy (as I proposed in 3
>intents: native/intended, similar and supports) at least would be extremely
>useful to avoid obvious ridiculous defaults.
>
>Jehan
>
>
>> --
>> David Faure, faure at kde.org, http://www.davidfaure.fr
>> Working on KDE Frameworks 5
>>
>>
>>
>> _______________________________________________
>> 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

I think the best option will be a FallbackMIMETYPE which just makes the app lower priority that other option. So gimp, Krita (just had a SVG open in it), some ide can just set it and use It. Another important thing will be to extend the mimetype definitions so mimetypes can inherit mimetype of another mimetype so it reduce the need to set so many mimetype(Especially important for text editor where almost any editor that can handle text/plain can handle other mimetypes in text/ making automatic fallback will help too)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20210504/e863525b/attachment-0001.htm>