Bug 407552

SUMMARY

If ~/.local/share/applications/SOMETHING.desktop is a symlink
Krunner will not read changes to the file content.
Even killing and restart krunner, or even killing and restarting plasma will not re-read the .desktop file content.

STEPS TO REPRODUCE

# ~/.local/share/applications/test-nolink.desktop
[Desktop Entry]
Name=test-nolink
Exec=/bin/bash -c "echo nolink... changes picked up immediately; read -p 'press any key'"
Terminal=true
Icon=xterm
#####################################################

# ~/.local/share/applications-test-symlinked.desktop
[Desktop Entry]
Name=test-symlinked
Exec=/bin/bash -c "echo symlinked... changes not picked up; read -p 'press any key'"
Terminal=true
Icon=xterm
#####################################################

ln -s ~/.local/share/applications-test-symlinked.desktop ~/.local/share/applications/test-symlinked.desktop


OBSERVED RESULT

Change anything in the symlinked file... The icon, the command line, the name... Changes are never picked up. Even restarting krunner or all of plasma won't pick up changes.

Meanwhile, changes make to the non-symlinked file are picked up very quickly.


EXPECTED RESULT

Whether the .desktop file is a file or on the other side of a symlink, changes should be picked up quickly, at the very least the changes should be seen after krunner is restarted.


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.15.5
(available in About System)
KDE Plasma Version: 5.15.5
KDE Frameworks Version: 5.57.0
Qt Version: 5.12.3
Kernel Version: 5.0.13-arch1-1-ARCH
OS Type: 64-bit

ADDITIONAL INFORMATION

Using Dotbot or other Dotfiles scripts to manage configuration files across many machines is very helpful, so symlinks inside ~/.local/share/applications may get increasingly common. Even on a single machine, much better to keep important configuration safely archived this way.