Bug 512378 - Desktop shortcuts cannot be moved to a folder and still work
Summary: Desktop shortcuts cannot be moved to a folder and still work
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Desktop icons & Folder View widget (other bugs)
Version First Reported In: 6.5.2
Platform: Debian testing Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-11-20 10:44 UTC by John
Modified: 2025-12-08 15:32 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
A folder called 'Remote' on the Desktop, with its content (4 not working shortcuts) on the left side. (152.62 KB, image/png)
2025-11-20 10:44 UTC, John
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John 2025-11-20 10:44:27 UTC
Created attachment 186979 [details]
A folder called 'Remote' on the Desktop, with its content (4 not working shortcuts) on the left side.

SUMMARY
Desktop shortcuts cannot be moved to a folder or sub-folder and still work like they work when they are at the root of the Desktop folder.

STEPS TO REPRODUCE
1. Have a few shortcuts on the Desktop that call some  command line tools or programs and maybe to games too.
2. Create a folder on the Desktop.
3. Move those shortcuts into that newly created folder.
4. Enter that folder and then double-click or click+Enter on them to open the tool or program they  are for.

OBSERVED RESULT
The tool or program they belong to is not called anymore so it doesn't open.
The .desktop file opens in Kate instead to edit it's content, which I already did before, when I created them.

EXPECTED RESULT
I expected that the tool or program that they lead to / target is still called exactly as if they were at the root of the Desktop.
When I was using Windows 7 and I had the Desktop filled with too many shortcuts to games as I had many games installed, one day I decided to make a folder called Games on the desktop and move them all inside it.
I could still open the games normally like they were at the root of the Desktop itself.
Now I remember that and I wanted to do the same for this use case:
Today, I needed scrcpy to mirror my phone's screen and camera and do that both when it's wired and when it's not (so on wireless).
Since I don't know how to make a shortcut that calls scrcpy with 4 different sets of arguments, I have decided the easiest would be to just make 4 desktop shortcuts that call scrcpy with 4 different sets of arguments.
The shortcuts work great, so I don't have to open the terminal and type all the arguments all the time.
The problem is that now I have 4 new desktop shortcuts, which are a lot, considering that I have others too.
So I re-did what I did on Windows 7 for the games and move them all in a newly created folder called Remote.
But the big problem is that they just do not work from there and I'm forced to have these 4k shortcuts at the root of the Desktop itself, which is not nice at all as it's too much clutter!
I added an attachment for better understanding what I have tried.


SOFTWARE/OS VERSIONS
Linux
KDE Plasma Version: 6.5.2 
KDE Frameworks Version: 6.18.0
Qt Version: 6.9.2


ADDITIONAL INFORMATION
I would really appreciate if you fixed this problem so it works like it did on Windows 7.
After it's fixed, I want to make a few folders for games too and move them all there, like a Games folder for all of them or a structure like this
Games
  -- Shooters
-- Platformers
-- Puzzles

So i want that the shortcuts that are in a sub-folder of the folder created on the Desktop work too as that would feel much more organized when many things are installed.
Comment 1 TraceyC 2025-12-04 17:53:37 UTC
I can reproduce this on git-master, using a shortcut for Firefox that opens a specific profile

Ex:
Program: firefox
Arguments: %u -p profile_name
Comment 2 John 2025-12-05 22:51:17 UTC
(In reply to TraceyC from comment #1)
> I can reproduce this on git-master, using a shortcut for Firefox that opens
> a specific profile
> 
> Ex:
> Program: firefox
> Arguments: %u -p profile_name

The fact that you tried to reproduce it with Firefox, reminded me that when you download the Tor browser from its official website:
https://www.torproject.org/download/
As it's missing from some of the distros' native repositories or for having a newer version of it...
And extract somewhere, you will have a 'tor-browser' folder with this content:
- Browser (folder)
- start-tor-browser.desktop (shortcut)

The shortcut has this content:
[Desktop Entry]
Type=Application
Name=Tor Browser Setup
GenericName=Web Browser
Comment=Tor Browser is a privacy-focused web browser designed to minimize tracking and fingerprinting, using the Tor network to protect your privacy and anonymity.
Categories=Network;WebBrowser;Security;
Exec=sh -c '"$(dirname "$*")"/Browser/start-tor-browser || ([ ! -x "$(dirname "$*")"/Browser/start-tor-browser ] && "$(dirname "$*")"/start-tor-browser)' dummy %k
X-TorBrowser-ExecShell=./Browser/start-tor-browser --detach
Icon=web-browser
StartupNotify=true
StartupWMClass=Tor Browser

And it's icon is not showing up, like it did before! (I'm not sure if before it showed up from the beginning or only after you started it the first time. Maybe it was the later)
Double-clicking on it also doesn't work, like it did before! (it just opens it for viewing / editing it in Kate, so the icons will never show now)

And when you download Firefox stable, beta, nightly, ESR or  developer version from its official website:
https://www.firefox.com/en-US/download/all/desktop-release/linux64/en-US/
https://www.firefox.com/en-US/download/all/desktop-beta/linux64/en-US/
https://www.firefox.com/en-US/download/all/desktop-nightly/linux64/en-US/
https://www.firefox.com/en-US/download/all/desktop-esr/linux64/en-US/
https://www.firefox.com/en-US/download/all/desktop-developer/linux64/en-US/
You will have a 'firefox' folder and inside, besides the many other folders and files, you have the 'firefox' executable.
Double-clicking on the 'firefox' executable doesn't start the web browser like before!
And it just shows a warning at the top with this text:
"For security reasons, launching executables is not allowed in this context."
On a red background.

Since LibreWolf, the browser that I'm using, is a Firefox fork, but doesn't have a download in an archive format, I looked at other Firefox forks and I tried this one: x86 64-bit GTK3, from 
https://www.basilisk-browser.org/download.html
Extracted it and did the same thing as with Firefox itself,, entered the 'basilisk' folder and double-clicked on the 'basilisk' executable.
It happened the same thing as with Firefox, the browser didn't open and the same message appeared at the top.
I assume this is similar to other Firefox forks that give you archives or even other programs that give you archives to extract and run.

Could this 4 regressions (missing icon and Tor browser not starting anymore, and both Firefox + Basilisk not starting anymore) be related in any way with the .desktop shortcuts not working anymore on the ~/Desktop when they are put in 1-2 folders deep?

Thank you very much Tracey for looking at it!
Comment 3 TraceyC 2025-12-08 15:32:59 UTC
(In reply to John from comment #2)
> Could this 4 regressions (missing icon and Tor browser not starting anymore,
> and both Firefox + Basilisk not starting anymore) be related in any way with
> the .desktop shortcuts not working anymore on the ~/Desktop when they are
> put in 1-2 folders deep?

This sounds like two different bugs. Can you please create a new bug report for the browsers not starting and reference this one?

> Thank you very much Tracey for looking at it!

You're welcome!