Bug 492754

Summary: "Command or Script" shortcuts completely break desktop files
Product: [Applications] systemsettings Reporter: Brodie Robertson <brodierobertson54321>
Component: generalAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: ad.liu.jin, alanas.00, grzesiek11, nate
Priority: NOR    
Version: 6.1.4   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In: 6.2.0
Sentry Crash Report:

Description Brodie Robertson 2024-09-07 14:39:12 UTC
SUMMARY
When you make a "Command or script" shortcut Plasma makes a desktop file in ~/.local/share/applications for running that command. The name of the file is the command used that is command, for additional shortcuts on the same command a number is a appended to the name as in command-2.desktop, command-3.desktop, etc.

Where this becomes a problem is with the first command which is called command.desktop, not appending any number which creates a local user override for that command. For user scripts this isn't a problem but when that command is an application on your system like alacritty, where it will generate alacritty.desktop if the first shortcut made isn't simply just opening the application, any options being passed into the application will be used by desktops that naively use the desktop file to open the application such as COSMIC.

For users that only ever use Plasma this isn't an issue but for people that run multiple desktops it causes Plasma to break the basic behavior on those desktops, and when you fix it on those desktops it breaks the shortcut on Plasma

STEPS TO REPRODUCE
1. Make a "Command or Script" passing options into the application in Plasma
2. Pin that command to the COSMIC system tray
3. Open the pinned application in COSMIC

SOLUTION
Never use the base name of the command for these additional desktop files being generated, always append a number to it. My preferred solution would be stop generating desktop files for the Plasma shortcut system but that would be a much bigger solution to deploy.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
Comment 1 Grzesiek11 2024-09-11 23:33:15 UTC
Going by the XDG Desktop Entry Specification, Plasma should create those desktop files with a vendor prefix, such as `org.kde.shortcut`. This should avoid conflicts with other software.
Comment 2 alanas.00 2024-09-12 04:59:04 UTC
(In reply to Grzesiek11 from comment #1)
> Going by the XDG Desktop Entry Specification, Plasma should create those
> desktop files with a vendor prefix, such as `org.kde.shortcut`. This should
> avoid conflicts with other software.

kglobalacceld also looks for *.desktop files in ~/.local/share/kglobalaccel
Comment 3 Jin Liu 2024-09-12 05:12:35 UTC
(In reply to alanas.00 from comment #2)
> kglobalacceld also looks for *.desktop files in ~/.local/share/kglobalaccel

Yes, but kglobalacceld no longer runs in Wayland.
Comment 4 David Edmundson 2024-09-12 05:49:47 UTC
Git commit 38cfc065b4b0a994227c0f0751668dd2447d70e6 by David Edmundson.
Committed on 12/09/2024 at 05:49.
Pushed by davidedmundson into branch 'master'.

Add custom prefix to user generated desktop files made from shortcuts KCM

The shortcuts KCM re-uses desktop files to store launchers for custom
commands. This is extremely sensible design as it is something being
launched and the design we want. Semantically we're creating a new entry
point. It's the only way you'll get the right cgroup mapped on launch. 

However the name entered by the user could clash with something on the
system which is something we don't want. Most apps are prefixed with the
correct reverse DNS prefix so it's a rare case, but not all.

This was seen in the wild by a user overriding alacritty.desktop by
accident.

Adding a custom prefix for user-generated files should avoid any
potential clash.

Fixed-in: 6.2

M  +1    -0    kcms/keys/kcm_keys.cpp

https://invent.kde.org/plasma/plasma-desktop/-/commit/38cfc065b4b0a994227c0f0751668dd2447d70e6