SUMMARY If you use something like kwrite for editing files and it is not explicit set as default app and you install for example builder, then all files which are not bound are opened by lesser alphanumerical named app. EXPECTED RESULT The current (single or topmost) implicit program should be explicit if a new app capable of handling this MIME-type, so that the behavior of opening should not change. PS OT: when are bugs recognized (https://bugs.kde.org/show_bug.cgi?id=423144)? Linux/KDE Plasma: 5.20 but way back
Is this bug specifically about the "Recent Documents" and "Desktop Search" runners? I feel like that is an issue somewhere in the frameworks :)
Meant it overall and didn't know where to put it. There are to many projects. You cannot expect a "customer" to go through all categories. You can push it where it belongs.
Can you clarify a bit? Are you saying that when you install GNOME Builder, it becomes the default app for opening text documents even though KWrite is installed?
It was not a explicit mime-type association, therefore the alphanumeric higher "builder" (b before k in kwriter) became implicit the new default. A single capable program running this mime-type became implicit default. Now there is a new one. Defaults change.
So it seems the problem is that installing a new app can cause existing documents to open with the new app, overriding the old default setting for which app opens the document. This is definitely not a KRunner problem. I don't even know if it's necessary a KDE problem. The way apps register mimetypes and how the system chooses an app is governed by some FreeDesktop specs. Needs input from someone more experienced than me.
IFAIU, that's standard behaviour with mime type handling, which isn't KDE-sepcific. Please check /usr/share/application/mimeinfo.cache and/or ~/.local/share/application/mimeinfo.cache (the latter overrides the former); these files are updated automatically when you install a new app with a .desktop file that has a MimeType= entry; if a mime type doesn't have an explicit default handler set, the first one in the list from mimeinfo.cache is used, e.g. for text/plain on my system: $ grep text/plain /usr/share/applications/mimeinfo.cache text/plain=com.github.johnfactotum.Foliate.desktop;okularApplication_txt.desktop;org.gnome.gedit.desktop;org.kde.kate.desktop;org.kde.kwrite.desktop;writer.desktop;
Ahmad: please point me to the KDE code that uses mimeinfo.cache :-) (we don't use it, we have our own cache, ksycoca) What matters instead is 1) mimeapps.list (i.e. user configuration) 2) the InitialPreference in .desktop files (KDE-specific mechanism to avoid this exact problem, in theory) Assuming you had never installed Builder before, it shouldn't be in your mimeapps.list. So the question is, does its desktop file come with an InitialPreference field, and if so, is it greated than KWrite's which is set to 8?
(Thanks for the clarifications o/).
Would ordered by date instead of alphanum solve the problem or appending newcomers to the explicit list? Other example: have not needed mkvbuilder before, .mkv files was assoc to vlc, installed mkvbuilder, .mkv was bound to mkvbuilder. This has just one assoc, a program with multiple capabilities would overthrow the last default program, if it is higher in alphanum. Don't be to attached to the provided examples. Every distro has this problem. Or is this even a FreeDesktop.org problem?
Before we invent solutions, can we pinpoint the actual problem? My question still stands: does the GNOME Builder desktop file come with an InitialPreference field?
OK, for vlc vs mkvbuilder I guess none of them have an InitialPreference since they are not KDE apps. And I assume you didn't have either one in mimeapps.list? I'll have to double-check if alphabetical sorting is really what's happening or if it's more or less random. But I think the freedesktop.org idea for solving this was simply that distros would prepare global kde-mimeapps.list files for most common mimetypes. I wonder if they do, though. I see a /usr/share/applications/gnome-mimeapps.list on my system (OpenSUSE) but no kde-mimeapps.list. Maybe they thought "no need, since KDE uses InitialPreference" .... but that's not true for non-KDE apps :) Anyhow, in the absence of a *-mimeapps.list entry, I see your point about using modification time of the desktop file rather than alphabetical sorting (if indeed that's what the code does). But will this really match time of installation, or time when the binary package itself was created? I just noticed a /usr/share/applications/gens.desktop from 2008 on my current system, which I only installed a few months ago... :) Maybe a special case because the RPM was "converted from a deb file", but still, this is something to double-check before we use mtimes.