Sorry for the late reply. I can generally launch applications such as Firefox, Dolphin, Konsle via launch menu, or from pinned icons in the taskbar. Also via KRunner or terminal. Only the association between app/icon and running program is not working, which causes Spectacle in particular to fail. So it sounds like we’re having different issues.
In my case, in dev session, I have the desktop file in /usr, and the hotkey launches the Spectacle binary in my home dir. So I guess either you are actually checking that the desktop file is in root, or the checking is buggy.
Then it would affect your normal session. The dev session script overrides systemd service files by copying files to /run, but it won’t work for desktop and dbus files due to security checkings.
There’s an MR (Draft: use systemd-sysext for plasma-dev session + fix dbus (!1715) · Merge requests · Plasma / Plasma Workspace · GitLab) using systemd-sysext that solves these issues quite cleanly, by overlaying your ~/kde/usr onto /usr via overlayfs. You can try that. But it is annoying in its own way that you have to temporarily remove the overlay to install any distro package.
Yes, it should be added to the wiki page.
Alright folks, I fixed Spectacle and Plasma task associations (complete with hover window previews) on my system. What @jinliu mentioned was not necessary in this case - note that I already have a fix for system-level services (KAuth in particular), as per further up in the thread.
Instead, there appears to be a bug in kbuildsycoca that populates application directories in the right order (local / user / higher priority first, system / lower priority last) but then overwrites an application service entry from earlier (higher priority) directories with another entry from a later (lower priority) directory in an apparent violation of priority order. For my setup where many apps exist both in local/build directories and system directories, this means that e.g. the system Spectacle replaces my local dev session Spectacle, and therefore the local Spectacle’s executable can’t be associated with its .desktop file.
I’ll have to verify that I’m actually reading this right, because if so, that’s a major bug in kbuildsycoca / KApplicationTrader. Can it actually be that a dealbreaker like that has lingered there for years without anyone else having encountered it? But it would also explain why my local Firefox menu entry edits never seemed to be picked up by the launch menu. Anyway, I need to boil this down to a test case and see what smarter people are going to say on the MR that I’m going to submit once I’m more certain.
[Edit: My first draft was obviously not the right fix. Works for me but not correct. Need to read up some more on this code and XDG menu files.]
Well. Obviously there was no bug in kbuildsycoca. That’s good. After some more debugging, I determined that the expanded list of <DefaultAppDirs/> was indeed in the correct order after menu parsing:
<AppDir>/usr/local/share/applications</AppDir>
<AppDir>/var/lib/flatpak/exports/share/applications</AppDir>
<AppDir>/home/kpetso/.local/share/flatpak/exports/share/applications</AppDir>
<AppDir>/home/kpetso/build/prefix/share/applications</AppDir>
<AppDir>/home/kpetso/.local/share/applications</AppDir>
With more specific / higher-priority directories further down, as it should be in an XDG menu file. However, /usr/share/applications was missing.
Why? Because it had been re-inserted further towards the bottom by the <DefaultMergeDirs/> element. Turns out I had an old /etc/xdg/menus/applications-merged/cisco-anyconnect.menu entry installed that didn’t just add a menu entry, but also (re-)specified /usr/share/applications as <AppDir>, thereby dragging it from the top (lowest priority) to the bottom (highest priority). And thus all system-wide .desktop files took priority over my local ones.
So, I’ve long not been using Cisco Anyconnect and deleted that sucker of a merged .menu file. Now my desktop works as intended.
YAY.
Thanks everyone. Let’s put this long thread to rest.
1 Like
Great investigation!