SUMMARY STEPS TO REPRODUCE 1. Drag folder to desktop and select "Add icon". 2. Click on icon in an attempt to open the folder. 3. OBSERVED RESULT Launching *folder name* (Failed) The desktop entry file /home/banzaigtv/.local/share/plasma_icons/*folder name*.desktop is not valid. EXPECTED RESULT Folder should have opened in Dolphin. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Arch Linux (available in About System) KDE Plasma Version: 5.20.0 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.1 ADDITIONAL INFORMATION
Can confirm. FWIW you can work around this by selecting the "Link here" item in the drop menu.
I want icons pinned to a hidden panel for quick access without cluttering the desktop with shortcut links, though. This was not an issue in Plasma 5.19.5 and earlier.
*** Bug 427674 has been marked as a duplicate of this bug. ***
As another workaround, Right-click > Open with > Dolphin should work.
Takes longer than simply left-clicking the icon on the panel.
Sure, workarounds are typically worse than having the bug fixed. :) We'll investigate.
I too have this annoyance, in panel icons which are links but now open up a warning instead: "This will start the program: Foldername If you do not trust this program, click Cancel" When I click on Continue, I get another warning: "The desktop entry file /home/LLL/.local/share/plasma_icons/LLL.desktop is not valid." Operating System: Arch Linux KDE Plasma Version: 5.20.0 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.1 Kernel Version: 5.8.14-arch1-1 OS Type: 64-bit Processors: 4 × Intel® Core™ i5-2500K CPU @ 3.30GHz Memory: 31.3 GiB of RAM Graphics Processor: GeForce GTX 1050/PCIe/SSE2
Yeah, that's the same issue.
*** Bug 428100 has been marked as a duplicate of this bug. ***
It only affects *.desktop files with a line "Type=Link" If the line is "Type=Application", it works normally.
(In reply to Walther Pelser from comment #10) > It only affects *.desktop files with a line "Type=Link" > If the line is "Type=Application", it works normally. Where do I find the file and change the line?
The desktop icons point to /home/*/.local/share/plasma_icons/ (* is a placeholder for the username). The desktop files there in could be opened and manipulated by kate. But I could not change the Type if it is a file to become opened. My workaround, if I do not want to use the right-click, to drag and drop /usr/share/applications/org.kde.dolphin to the desktop and customize that, so that dolphin opens a specific file. (My OS is openSUSE Tumbleweed, but this might be the same with your OS)
I can confirm that. The .desktop file functions fine when entered/opened in Dolphin, but not when clicked on as a widget. Clearly a bug in the widget. Will investigate.
Found the problem. The applet was ported from KRun to KIO::ApplicationLauncherJob. But the applet supports more than just applications; it can also open arbitrary paths. The console output is a clue: kf.service.services: The desktop entry file "/home/nate/.local/share/plasma_icons/bin.desktop" has Type= "Link" instead of "Application" or "Service" kf.kio.gui: "The desktop entry file\n/home/nate/.local/share/plasma_icons/bin.desktop\n is not valid.
I'll fix it. Working on a patch.
(In reply to Nate Graham from comment #15) > I'll fix it. Working on a patch. Is it possible that it will be patched in the Plasma 5.20.3 release?
(In reply to Nate Graham from comment #15) > I'll fix it. Working on a patch. Thanks!!!! (<:
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/398
(In reply to Joseph DeGarmo from comment #16) > Is it possible that it will be patched in the Plasma 5.20.3 release? Assuming my merge request above is merged in the next two weeks, yes!
(In reply to Nate Graham from comment #19) > (In reply to Joseph DeGarmo from comment #16) > > Is it possible that it will be patched in the Plasma 5.20.3 release? > Assuming my merge request above is merged in the next two weeks, yes! My own build of plasma5-workspace 5.20.2 with your modified iconapplet.cpp works. !! Thanks !
(In reply to Walther Pelser from comment #20) > (In reply to Nate Graham from comment #19) > > (In reply to Joseph DeGarmo from comment #16) > > > Is it possible that it will be patched in the Plasma 5.20.3 release? > > Assuming my merge request above is merged in the next two weeks, yes! > > My own build of plasma5-workspace 5.20.2 with your modified iconapplet.cpp > works. !! Thanks ! The new iconapplet.cpp has caused a new bug. Some of the icons Type=Application are not working correctly anymore. firefox.desktop f.i.: [Desktop Action PrivateBrowsing] Exec=firefox --private-window %u Name=New Private Browsing Window [Desktop Action ProfileManager] Exec=firefox --ProfileManager Name=Profile Manager [Desktop Action new-window] Exec=firefox --new-window %u Name=New Window [Desktop Entry] Actions=new-window;PrivateBrowsing;ProfileManager Categories=Network;WebBrowser;GTK; Comment[de_DE]=Web-Browser Comment=Web-Browser Encoding=UTF-8 Exec=/home/walther/.firefox/firefox/firefox GenericName[de_DE]=Web-Browser GenericName=Web-Browser Icon=firefox MimeType=text/html;application/xml;application/xhtml+xml;application/x-xpinstall;application/vnd.mozilla.xul+xml; Name[de_DE]=Firefox Name=Firefox Path= StartupNotify=true Terminal=false TerminalOptions= TryExec=firefox Type=Application X-DBUS-ServiceName= X-DBUS-StartupType= X-KDE-SubstituteUID=false X-KDE-Username= does not execute /home/walther/.firefox/firefox/firefox , but /usr/bin/firefox which in my case is another version of firefox. vlc.desktop has a line Exec=/usr/bin/vlc /home/walther/.vlc/vlc.xspf but does execute only /usr/bin/vlc without opening this file. could you test this? Or confirm it?
Yes I just fixed that in the latest version of the merge request. In the future can you leave comments in the merge request itself rather than here? Thanks!
Git commit 87b562063b9580c3996c88654368f924a59a061a by Nate Graham. Committed on 30/10/2020 at 04:51. Pushed by ngraham into branch 'master'. [applets/icon] Handle non-Applications URLs again In the past, this applet naively passed the URL to KRun when clicked on or something was dragged on top of it. However during porting away from KRun, it was ported to KIO::ApplicationLauncherJob, which only handles applications, not other types of URLs. This commit fixes that by making it use KIO::OpenURLJob (which can handle applications as well as arbitrary URLs) when it's clicked on. We also short-circuit the application-specific logic when something is dragged on it and it's not an application, which allows the non-application logic to be reached. FIXED-IN: 5.20.3 M +12 -7 applets/icon/iconapplet.cpp https://invent.kde.org/plasma/plasma-workspace/commit/87b562063b9580c3996c88654368f924a59a061a
Git commit 2ff78e97ccf2763f6f4933cc32a6c95d5642c87f by Nate Graham. Committed on 30/10/2020 at 04:52. Pushed by ngraham into branch 'Plasma/5.20'. [applets/icon] Handle non-Applications URLs again In the past, this applet naively passed the URL to KRun when clicked on or something was dragged on top of it. However during porting away from KRun, it was ported to KIO::ApplicationLauncherJob, which only handles applications, not other types of URLs. This commit fixes that by making it use KIO::OpenURLJob (which can handle applications as well as arbitrary URLs) when it's clicked on. We also short-circuit the application-specific logic when something is dragged on it and it's not an application, which allows the non-application logic to be reached. FIXED-IN: 5.20.3 (cherry picked from commit 87b562063b9580c3996c88654368f924a59a061a) M +12 -7 applets/icon/iconapplet.cpp https://invent.kde.org/plasma/plasma-workspace/commit/2ff78e97ccf2763f6f4933cc32a6c95d5642c87f
*** Bug 428550 has been marked as a duplicate of this bug. ***