Even if I set up file associations the way I want in the system settings, they don't work as expected in gtk applications. So far I found two main reasons for that: 1. kde creates some desktop files with an "Exec[$e]" key; those files are rejected by glib - "Invalid key name: Exec[$e]" (in gkeyfile.c, g_key_file_parse_key_value_pair function) 2. Even if I avoid the first problem, glib is checking a bunch of configuration files (mimeinfo.cache, defaults.list, mimeapps.list) in a bunch of places (~/.local/share/applications, /usr/local/share/applications, /usr/share/applications) and it seems that they are not in sync with the kde settings, and I haven't found any program that edits them in an organized way, apparently I have to edit them manually. Also can't figure out how they ended up with the current contents. Reproducible: Always Expected Results: gtk apps should use the file associations I set in kde (there should at least be an option for that, if not always desired)
Point 2 seems to happen mainly with kde defaults - if I don't make any changes, it doesn't write to those configuration files, and glib finds a different default (in /usr/share/applications/mimeinfo.cache, which seems to be ignored by kde)
One more finding: - if I edit mimeapps.list and set image/jpeg to have kde-gwenview.desktop followed by zzz-gimp.desktop (what's up with the zzz?! anyway...) then kde opens with gwenview and gtk opens with gimp - if I set image/jpeg to have kde4-gwenview.desktop (note the 4) followed by zzz-gimp.desktop, then kde opens with gimp and gtk opens with gwenview (!!!) I'm not sure why kde ignores kde4-gwenview.desktop, but effectively this seems to defeat the purpose of having a common configuration file. In order to get gwenview to be used in both environments, I need to put BOTH kde-gwenview.desktop and kde4-gwenview.desktop as the first two associations (in any order)
In openSUSE seems that GTK progams use /usr/share/applications/defaults.list (symlink to /var/cache/gio-2.0/gnome-defaults.list) and don't respect ~/.local/share/applications/mimeapps.list I can not found, that user's file could override /usr/share/applications/defaults.list ...
Some distributions have tools to include KDE apps in GNOME default application's list, see: https://bugzilla.novell.com/show_bug.cgi?id=867135
Hi ! I noticed a strange behavior regarding files associations, that only affect some GTK apps like Firefox / Thunderbird. I may file another bugreport if necessary. How to reproduce : 1) install a clean KDE Neon distribution (or Manjaro KDE, same behavior). Plasma 5.12.1. 2) install wine 3) check the files associations for PNG and JPEG images in the KDE settings : gwenview is first, wineserver is second 4) try to open a PNG or JPG in Dolphin : Gwenview is indeed invoked 5) try to open a PNG or JPG in Firefox : wineserver is invoked !! WORKAROUND 6) go back to the files associations preferences, move some items back and forth in the PNG / JPG lists ; save them 7) now, Gwenview will be invoked in Firefox, even though the list appears to be the same ! Gwenview is indeed displayed as "default" in the FF/TB preferences (while it was wineserver before) SO : the KDE files associations list IS taken into account by Firefox / Thunderbird BUT it has to be modified / saved first for some unknown reasons.
Mahendra: you seem to be describing a Firefox bug. That's not anything we can do anything about in the KDE community, please report that to the Firefox developers. And since Firefox isn't a GTK/glib application (AFAIK), it's not even related to this bug report.
@David Faure : this is definitely what I was thinking too at first (FF&TB bug - not real GTK apps). However what rang me a bell is the fact they do behave properly if the associations order is modified / saved again in the KDE control center. Unrelated ? Cheers !
(In reply to David Faure from comment #6) > Firefox isn't a GTK/glib application (AFAIK) If Firefox somehow isn't a GTK/glib application (really?!), it certainly looks and acts like one, and the file associations seem to be affected in the same way by the same config files.
I was planning to file this bug myself, but found this bug report, so I'll post my investigation here. SUMMARY When using GTK apps like Firefox in a KDE desktop, files open in the wrong apps compared to in KDE. STEPS TO REPRODUCE 1. Install KDE on a Linux distro. 2. xdg-mime query default image/png 3. gio mime image/png OBSERVED RESULT xdg-mime (delegating to ktraderclient5) matches file associations in Qt/KDE apps, and picks reasonable default apps (based on the InitialPreference values in .desktop files). gio mime matches file associations in GTK apps or Firefox, and picks unreasonable default apps, like opening images in gimp.desktop or okularApplication_kimgio.desktop instead of org.kde.gwenview.desktop. (This is approximately alphabetically sorted, and matches the order in /usr/share/applications/mimeinfo.cache.) EXPECTED RESULT In a desktop configured by KDE, gio mime should match file associations in KDE apps, and have reasonable defaults. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.21.90 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 Kernel Version: 5.12.7-arch1-1 (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor Memory: 15.6 GiB of RAM Graphics Processor: NVIDIA GeForce GT 730/PCIe/SSE2 ADDITIONAL INFORMATION This issue was already analyzed 7 years ago in the Firefox bug tracker, at https://bugzilla.mozilla.org/show_bug.cgi?id=727422#c24. To summarize/elaborate, KDE extends the .desktop file spec with KDE-specific keys. For example, apps can specify InitialPreference (a default priority) which KDE (and only KDE to my knowledge) uses to pick default apps, if the user doesn't override the order through ~/.config/mimeapps.list (or /etc/xdg/mimeapps.list or /usr/share/mime/mimeapps.list). As a result, when opening files in KDE, KDE apps (the only ones to specify InitialPreference) are picked first ahead of other apps by default. For example, /usr/share/applications/org.kde.gwenview.desktop has InitialPreference=8. GNOME apps (which use glib's g_app_info_get_all_for_type/etc.) do not use these priorities, so opening downloaded files in Firefox defaults to mimeinfo.cache (which is usually in alphabetical order, which is not what you generally want). I think KDE should export the InitialPreference values to mimeapps.list. But the exact design involves multiple decisions that trade-off between multiple desired/undesired properties. One decision is choosing whether to install to /usr/share/applications/ (overriden by /etc/xdg/mimeapps.list) or ~/.config/ (can't be overriden except by per-user config). Another is how to handle mismatches between the .desktop files and mimeapps.list; we need to handle both adding/removing applications or packages changing InitialPreference, and the user editing mimeapps.list (though perhaps users shouldn't be editing /usr/share/applications/ when /etc/xdg/ is a cleaner way to override it?). Yet another is choosing whether to write mimeapps.list or KDE-mimeapps.list. /etc/xdg/mimeapps.list seems to work on both GNOME and KDE. However I ran into some roadblocks while setting it up. I tried copying my own mimeapps.list to /etc/xdg/mimeapps.list (then renaming my own to deactivate it), but forgot to `chmod 644 /etc/xdg/mimeapps.list` before testing MIME lookup. Apparently KDE apparently "cached" that that file was inaccessible, and didn't use it even after I ran `chmod 644 /etc/xdg/mimeapps.list` and `update-desktop-database /etc/xdg`, until I deleted and recreated mimeapps.list. An alternative to exporting preferences to mimeapps.list (which can be read by update-desktop-database) is extending or rewriting update-desktop-database to use InitialPreference values when generating mimeinfo.cache files. Yet another alternative is to tell glib to add support for InitialPreference values ;). Though I don't know how GNOME supports default apps, or reordering apps system-wide or on a per-user level (I assume per-user reordering is done through ~/.config/mimeapps.list). Does GNOME allow setting one app above another for *every* file that both can handle? I wish KDE allowed for that, but I don't think it's possible without editing /usr/share/applications/ and hoping it doesn't get overwritten in a package update. I'm going to be experimenting with writing a daemon or tool of my own, to test various approaches to generating mimeapps.list or mimeinfo.cache. If anyone is interested in my efforts, or wants to do something similar "officially" in the KDE or XDG projects, let me know!
*** Bug 436407 has been marked as a duplicate of this bug. ***
Since `gio mime image/jpeg org.kde.gwenview.desktop` works fine for me amd persists even after restarts and system upgrades, my guess would be, that it'd be sufficient if Plasma uses the GIO VFS API [1] to set the desired mimetype associations Gnome/GTK apps. [1] https://developer.gnome.org/gio/stable/ch01.html
To my knowledge, GNOME determines file associations through a standard XDG lookup; it's technically performed using VFS, but I don't think it matters for KDE trying to write default apps. GTK's "Default Applications" settings dialog uses g_app_info_get_recommended_for_type and g_app_info_get_default_for_type to fetch the current default app, and g_app_info_set_as_default_for_type to set a default app. And editing ~/.config/mimeapps.list is necessary and sufficient to change GNOME's default apps in both Files and Default Applications. Caveats: - I haven't looked into how `gio mime` sets associations, but I assume it works the same way. - Apparently g_app_info_get/set...() (https://developer.gnome.org/gio/stable/GAppInfo.html) are actually implemented in terms of the GIO VFS API. However I've only seen them query the various mimeapps.list/mimeinfo.cache files, never any virtualized apps. I don't know if it's necessary for KDE to shell out to these APIs; I was planning to just write tools that interface with the standard XDG MIME/application files.
Decided to install GNOME to see how it handles default applications. I had a lot less "mishmash of broken settings and broken default applications" this time around, compared to my last attempt at multiple DEs. GNOME has a "Default Applications" settings page. It works by writing dozens of file associations into ~/.config/mimeapps.list (this file applies to all DEs). If you set VLC as your default audio player, GNOME will first set "audio/x-vorbis+ogg" to launch VLC by default, then set every MIME type supported by VLC matching "audio/*" to launch VLC by default (skipping VLC's video MIME types, and audio/* MIME types that VLC doesn't support). This is a useful tool to set default apps (though it doesn't have the option to exclude specific file types from being assigned to your new default app, which is sometimes useful). Unfortunately KDE has no equivalent convenient tool to change MIME types. Fortunately gnome-control-center also changes default apps in KDE, though it might come with a lot of GNOME dependencies (not sure). In summary, GNOME doesn't follow InitialPreference like KDE does, resulting in suboptimal file associations. However GNOME makes it easy (unlike in KDE) for each user to set entire categories of MIME types to a single default app. (IDK if GNOME updates your account-local mimeapps.list's [Added Associations] or [Default Applications] when you install or uninstall apps.) So merely installing GNOME and setting default apps once is enough to fix file associations globally in all DEs, for as long as you use the same computer and user account. (There's a *lot* more depth including bugs where GNOME mixes up MIME aliases, but I don't know where to publish my writeup or whether to file a bug report.) I don't know if GNOME defaults to something dumb (like Wine Internet Explorer) for PDF files by default though, requiring manual fixing for each filetype (which is worse than KDE using good defaults out of the box). I still don't know the best route to take from now on, whether to convince GNOME to support InitialPreference, to write my own converter from InitialPreference to mimeapps.list, or from InitialPreference to mimeinfo.cache (replacing update-desktop-database). ---- Also, I think KDE needs an equivalent to GNOME's "Default Applications" settings page. (There's an old closed bug at https://bugs.kde.org/show_bug.cgi?id=211147, mentioning default images/videos which can be implemented like GNOME, but also default office suites which is more complex.) KDE Default Applications's current architecture is located at https://invent.kde.org/plasma/plasma-desktop/-/tree/master/kcms/componentchooser. It uses one C++ class per item (eg. the default browser is controlled by componentchooserbrowser.h/cpp) and hard-codes the logic used for each item. It currently lacks any items which use globs to change many MIME types in bulk. One way to rewrite it is in a more data-driven approach like GNOME's at https://gitlab.gnome.org/GNOME/gnome-control-center/-/blob/6c816e79e83383c11a07ab6a734cd8350c6c330e/panels/default-apps/cc-default-apps-panel.c#L27-35. However I don't know if doing so would lose out on functionality currently unique to each C++ class, like ComponentChooserBrowser using a BrowserSettings object. It seems that KDE Default Applications (at least "Web browser" and "File manager") also applies to other desktop environments, but I haven't researched how/why.
> EXPECTED RESULT > In a desktop configured by KDE, gio mime should match file associations in KDE > apps, and have reasonable defaults. I failed to convince people about InitialPreference on the xdg@freedesktop.org mailing-list. The conclusion was more along the lines of "in the absence of a saved preference, ask the user and write out the result in mimeapps.list" -- and also some improvements to the defaults by separating native mimetypes from other supported mimetypes. This hasn't resulted in a spec though, partly due to inaction on my side. Meanwhile if you like KDE's defaults and want them applied to non KDE apps, the solution is to generate a mimeapps.list file.
(In reply to David Faure from comment #14) > This hasn't resulted in a spec though, partly due to inaction on my side. Meanwhile (...) Thank you for discussing it with the XDG people! It would be great if you keep on it to turn it into a spec eventually. :)
*** This bug has been confirmed by popular vote. ***
According to https://specifications.freedesktop.org/mime-apps-spec/mime-apps-spec-latest.html#file, there's $XDG_DATA_DIRS/applications/$desktop-mimeapps.list, so why not to provide a kde-mimeapps.list with all the preferred applications by default instead of using a non-standard key? That should work for any XDG-compilant library and have effect only with XDG_CURRENT_DESKTOP=KDE
(In reply to David Faure from comment #14) > Meanwhile if you like KDE's defaults and want them applied to non KDE apps, > the solution is to generate a mimeapps.list file. This is required to comply with Freedesktop.org Mime Apps Spec: default KDE setup should include `/user/share/applications/mimeapps.list`. https://specifications.freedesktop.org/mime-apps-spec/latest/ar01s02.html
> Meanwhile if you like KDE's defaults and want them applied to non KDE apps, the solution is to generate a mimeapps.list file. Could we have the KCM do that automatically? Either automatically, or optionally?
KCM will do something only when changing the settings, yeah? It already does that afaik. The problem is with the default associations. KDE uses custom InitialPreference key in desktop files while it should provide /usr/share/applications/kde-mimeapps.list with all default preferences instead to be compliant with the XDG spec.
*** Bug 449234 has been marked as a duplicate of this bug. ***
One detail I failed to realize or mention earlier, is that in GTK file managers like Thunar (and probably Nautilus), opening a file in a particular app (even without setting it as default) actually sets a "soft" default file association by reordering the file format's entry in mimeapps.list [Added Associations]. For example, if you open Thunar, right-click a .zip file, and pick Open With -> Open With "Archive Manager" (or pick "Open With Other Application..." and in the dialog *don't* check "Use as default for this kind of file"), then ~/.config/mimeapps.list [Added Associations] gets a new entry `application/zip=org.gnome.FileRoller.desktop;...`, where org.gnome.FileRoller (Archive Manager) comes first. I think this is accomplished through g_app_info_set_as_last_used_for_type() (https://docs.gtk.org/gio/method.AppInfo.set_as_last_used_for_type.html -> g_desktop_app_info_set_as_last_used_for_type https://gitlab.gnome.org/GNOME/glib/-/blob/62a9a8a660fadf2355342b1d95c539432c666fe1/gio/gdesktopappinfo.c#L3865). KDE/Qt's Dolphin respects the "soft" default association from [Added Associations], but does not set [Added Associations] when you open a file in an app. In Thunar, if you open properties of a .zip file and set a default *there*, then a [Default Applications] entry gets created (probably g_app_info_set_as_default_for_type() https://docs.gtk.org/gio/method.AppInfo.set_as_default_for_type.html). At this point, Thunar's "Open With" menu still reorders the format's entry in [Added Associations], but the order's first entry is ignored in favor of the association in [Default Applications].
https://bugzilla.mozilla.org/show_bug.cgi?id=1304650 Relevant Firefox issue
Nate, would you mind to make this bug to the "15-minute bug initiative"? It's something one can very quickly discover when using a GTK application and it's very annoying. :) Until it's solved for everyone, this should work: ``` $ cat /usr/share/applications/mimeapps.list [Added Associations] [Default Applications] image/gif=org.kde.gwenview.desktop; image/jpeg=org.kde.gwenview.desktop; image/png=org.kde.gwenview.desktop; image/webp=org.kde.gwenview.desktop; [Removed Associations] application/pdf=chromium.desktop;claws-mail.desktop; application/rdf+xml=chromium.desktop; application/rss+xml=chromium.desktop; application/xhtml+xml=chromium.desktop; application/xhtml_xml=chromium.desktop; application/xml=chromium.desktop; image/gif=chromium.desktop; image/jpeg=chromium.desktop; image/png=chromium.desktop; image/webp=chromium.desktop; text/html=chromium.desktop; text/xml=chromium.desktop; x-scheme-handler/http=chromium.desktop; x-scheme-handler/https=chromium.desktop; ```
Seems sane!
I investigated this because Firefox was choosing gedit for plain/text instead of kate. For me the problem was not that we do not provide or generate a default mimeapps list or a that GLib is not following our 'InitialPreference' but my distro was providing a /usr/share/applications/defaults.list file which sets gedit as default. This file is not in the spec but something histotical and glib specific. With this file removed firefox correctly chooses kate . So there are two issues that we have a non-standard key that gio doesn't support and gio has a non-standard file that we do not know about.
The idea was that it's fine for Gnome to ignore our InitialPreference and it's fine for KDE to ignore Gnome's global file, since we want different defaults. But Gnome's global file was supposed to be called gnome-mimeapps.list, not defaults.list.
Isn't it the distro's fault of providing the legacy file?
> The idea was that it's fine for Gnome to ignore our InitialPreference and it's fine for KDE to ignore Gnome's global file, since we want different defaults. Yes but glib applications inside plasma will still open the "wrong" application since glib can't know InitialPreference. We would either need to generate a kde-mimeapps.list that respects the order or maybe more elegant teach update-desktop-database InitialPreference so in mimeinfo.cache the order is what we (KDE) expect and not alphabetically. > But Gnome's global file was supposed to be called gnome-mimeapps.list, not defaults.list. The seem to carry it has deprecated for backwards compat https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gdesktopappinfo.c#L1021 Maybe it could only be read in GNOME session guarded by an env var. >Isn't it the distro's fault of providing the legacy file? Yes. It illustrates that it is a hard problem with non-standard from both sides.
(In reply to David Faure from comment #27) > The idea was that it's fine for Gnome to ignore our InitialPreference and > it's fine for KDE to ignore Gnome's global file, since we want different > defaults. But Gnome's global file was supposed to be called > gnome-mimeapps.list, not defaults.list. I find that double clicking a deb file in the Firefox download manager opens Ark. I understand from this Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1304650 that Firefox uses g_app_info_get_default_for_type to work out what to open. What should I change to make the correct application open when I double click deb in the Firefox download manager? I have a file /usr/share/applications/defaults.list in my distro (Kubuntu) if that's any help.
(In reply to mcarans from comment #30) > What should I change to make the correct application open when I double click deb in the > Firefox download manager? I have a file /usr/share/applications/defaults.list in my distro > (Kubuntu) if that's any help. If I remember correctly, KDE well edits `$HOME/.config/mimeapps.list` when you customize your file associations. So, from ComponentChooser or from Dolphin, change the default application for .deb, then change back to your wanted application. I think that will solve your issue.
(In reply to Pols12 from comment #31) > (In reply to mcarans from comment #30) > > What should I change to make the correct application open when I double click deb in the > > Firefox download manager? I have a file /usr/share/applications/defaults.list in my distro > > (Kubuntu) if that's any help. > > If I remember correctly, KDE well edits `$HOME/.config/mimeapps.list` when > you customize your file associations. So, from ComponentChooser or from > Dolphin, change the default application for .deb, then change back to your > wanted application. I think that will solve your issue. I forgot to add that KDE itself opens the correct application. It is Firefox that opened the wrong one. However, I was alerted on r/kde to the Firefox config settings: widget.use-xdg-desktop-portal* which if all set to 1 force the use of portal and hence KDE associations.
(In reply to mcarans from comment #32) > I forgot to add that KDE itself opens the correct application. It is Firefox > that opened the wrong one. I know, but KDE gets default associations from KSycoca, so you need to force it to edit mimeapps.list with the method I gave (or to manually edit the file). However, if you have found a workaround, that’s it.
portal uses glib, not the KDE associations. IMO, KDE should really get rid of non-standardized additions, all other implementations don't support them.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2030
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kservice/-/merge_requests/179
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kservice/-/merge_requests/181
Git commit 89c68cd74ee439adf1ac8526b3e3780894c3157f by Harald Sitter. Committed on 13/02/2024 at 10:46. Pushed by sitter into branch 'master'. install a kde-mimeapps.list introducing a mimeapps.list has a number of advantages - formalized encoding of default choices based on xdg tech - non-kde apps will also respect this when inside a plasma session - it paves the way to drop our initialpreference tech which has various problems in a world where applications use any number of different xdg implementations of which not all will be privy to the initialpreference the list of defaults is seeded from the componentchooser kcm, plus discover defaults used in neon already (this file is part of plasma-desktop since mobile choices may be divergent, making it a bad fit for plasma-workspace) M +1 -0 CMakeLists.txt A +152 -0 kde-mimeapps.list https://invent.kde.org/plasma/plasma-desktop/-/commit/89c68cd74ee439adf1ac8526b3e3780894c3157f
Git commit dfca581a1fb934a1146286441cd051981c50b673 by Harald Sitter. Committed on 13/02/2024 at 11:12. Pushed by sitter into branch 'Plasma/6.0'. install a kde-mimeapps.list introducing a mimeapps.list has a number of advantages - formalized encoding of default choices based on xdg tech - non-kde apps will also respect this when inside a plasma session - it paves the way to drop our initialpreference tech which has various problems in a world where applications use any number of different xdg implementations of which not all will be privy to the initialpreference the list of defaults is seeded from the componentchooser kcm, plus discover defaults used in neon already (this file is part of plasma-desktop since mobile choices may be divergent, making it a bad fit for plasma-workspace) (cherry picked from commit 89c68cd74ee439adf1ac8526b3e3780894c3157f) M +1 -0 CMakeLists.txt A +152 -0 kde-mimeapps.list https://invent.kde.org/plasma/plasma-desktop/-/commit/dfca581a1fb934a1146286441cd051981c50b673
Git commit c347606b240bfd1c65f46abd43e65fffb1f18053 by Harald Sitter. Committed on 14/02/2024 at 09:15. Pushed by sitter into branch 'master'. kservice: remove InitialPreference Since this was a KDE specific feature it caused problems with interoperability. Applications based on other XDG implementations would entirely ignore it and by extension have a different idea of what application should be used to open a given mimetype. Instead we now rely only on the XDG provided facilities to manage preference. Specifically plasma-desktop is meant to ship a kde-mimeapps.list that encodes the Plasma default preferences and distributions are meant to ship *mimeapps.list to encode sensible preferences beyond that. M +5 -12 autotests/kmimeassociationstest.cpp M +10 -83 src/services/kservice.cpp M +0 -29 src/services/kservice.h M +1 -5 src/services/kservice_p.h M +7 -7 src/services/kservicefactory.cpp M +1 -1 src/services/kservicefactory_p.h M +4 -5 src/sycoca/kbuildservicefactory.cpp M +1 -1 src/sycoca/ksycoca.cpp https://invent.kde.org/frameworks/kservice/-/commit/c347606b240bfd1c65f46abd43e65fffb1f18053