Created attachment 153353 [details] screenshot comparing the results and showing spotify desktop file SUMMARY Whenever I search for some application, there is a moment where Kickoff Applet prioritizes the application command line rather than the name (I attached some screenshots). For example, when I type `CL` it shows the CLion IDE as the first candidate, but when I type `CLi`, it gives me Spotify as the first candidate (and I'm guessing it is looking at the command line, which has the `Client` word). I cannot count how many times I started typing `CL` and seeing the right result but having my fingers already in the process of typing the `i`, so the Enter is pressed right after and Spotify gets opened. STEPS TO REPRODUCE 1. Have both Spotify (Flatpak) and CLion installed 2. Type CL and CLi on Kickoff OBSERVED RESULT CLion comes when I type `CL` but Spotify comes when I type `CLi`. EXPECTED RESULT CLion being always prioritized because Spotify doesn't have `CLi` in its name, only in the command. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.0.6-arch1-1 / 5.26.2 (available in About System) KDE Plasma Version: 5.26.2 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 ADDITIONAL INFORMATION Spotify was installed through Flatpak.
Can you please attach the desktop files of (spotify and clion), and the ~/.local/share/krunnerstaterc file? Then I am able to exactly reproduce your setup. Looking at the code, it seems as if we slightly prefer the name over the exec value. Though the feature that often launched apps have a higher relevance might cause issues here.
Maybe we need the same fix as https://invent.kde.org/plasma/plasma-workspace/-/commit/ce7c10b31c315867817e860a7c4929892a3b4344 applied here?
If we were to say that we fully want to ignore flatpak exec values, we could do that too.
since the exec values for all Flatpak apps include an RDNS style identifier that will have random text in it, it probably makes sense.
Created attachment 153388 [details] Spotify client application desktop
Created attachment 153389 [details] JetBrains' Toolbox CLion desktop file
(In reply to Nate Graham from comment #4) > since the exec values for all Flatpak apps include an RDNS style identifier > that will have random text in it, it probably makes sense. I never thought about this, but now thinking that way, my CLion installation is managed by JetBrains Toolbox (which doesn't have a flatpak version yet), only Spotify is installed through Flatpak, and it seems to have a stable command line, JetBrains Toolbox tho, changes the command line every time the IDE is updated, because Toolbox allows multiple versions to be installed, not only EAP, but any version. That said, now I tried again, and typing `CLi` is bringing CLion first now, but that is because I've already launched it a couple of times, so I guess `~/.local/share/krunnerstaterc` would not help now, even tho, I will be attaching both desktop files anyway. I've confirmed, there a couple of `clion.sh` entries on my `krunnerstaterc`, so, whenever the IDE updates and Toolbox updates the desktop file, the same thing happens again (Spotify being suggested first), and maybe that's the reason I forget about this problem for some weeks or months. Sadly I don't know how this can be addresses only for JetBrains Toolbox case, changing Flatpak behavior may work for my specific case, but any other `.application` would cause this, it's not directly related to Flatpak's way of creating application files (not in this case). I completely understand now why this happens, Spotify was already launched dozens of times, CLion way more, but the problem is that CLion's installation path changes every update, so do the launch command. The only way I can think of is giving way more weight to the name rather than the command, but I'm sure this will affect how suggestions works and may confuse users.
>Sadly I don't know how this can be addresses only for JetBrains Toolbox case, changing Flatpak behavior may work for my specific case, but any other `.application` would cause this, it's not directly related to Flatpak's way of creating application files (not in this case). The reason we consider doing it for Flatpak is that the Exec line gets rewritten and contains quite a bit of additional text. This includes the app name in reverse domain notation, like "com.spotify.Client". I am not aware of other desktop files that contain such rewritten Exec lines.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2296
Git commit bead60d92f428e3a568fea8aa286c7e125b4c9cb by Nate Graham, on behalf of Alexander Lohnau. Committed on 03/11/2022 at 15:24. Pushed by ngraham into branch 'master'. runners/services: Do not parse exec of flatpaks This way we avoid false positives, especially from the RDN names. For example typing "kde" in order to launch KDevelop would cause the "ork.kde.kwordquiz" snap to show up too. M +4 -1 runners/services/servicerunner.cpp https://invent.kde.org/plasma/plasma-workspace/commit/bead60d92f428e3a568fea8aa286c7e125b4c9cb
Git commit d7a8719d53c798fd2219d98015c034823baa5419 by Nate Graham, on behalf of Alexander Lohnau. Committed on 03/11/2022 at 15:47. Pushed by ngraham into branch 'Plasma/5.26'. runners/services: Do not parse exec of flatpaks This way we avoid false positives, especially from the RDN names. For example typing "kde" in order to launch KDevelop would cause the "ork.kde.kwordquiz" snap to show up too. (cherry picked from commit bead60d92f428e3a568fea8aa286c7e125b4c9cb) M +4 -1 runners/services/servicerunner.cpp https://invent.kde.org/plasma/plasma-workspace/commit/d7a8719d53c798fd2219d98015c034823baa5419