SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Right click on desktop 2. Configure desktop and wallpapers 3. Wallpaper type: slideshow 4. Choose a folder OBSERVED RESULT Some folder works, some other appears empty, while they are not empty EXPECTED RESULT Until yesterday it was possible to set a non-empty folder as images container SOFTWARE/OS VERSIONS Operating System: KDE neon 5.26 KDE Plasma Version: 5.26.0 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Kernel Version: 5.15.0-50-generic (64-bit) Graphics Platform: X11 Processors: 2 × Intel® Core™ i3-7100 CPU @ 3.90GHz Memory: 7,7 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 Manufacturer: MSI Product Name: MS-7A74 System Version: 1.0 ADDITIONAL INFORMATION No problem with the media-frame. No problem with Dolphin. No problem with screensaver. Only the desktop wallpaper as slideshow (wallpaper as image works as expected)
I noticed that from today symlinked images are no more possible as desktop wallpaper: I guess that this is the reason of this behavior. It is something intentional? And why: is is very annoying.
Can reproduce that.
@Fushan When you mark something as RESOLVED INTENTIONAL, it's expected that you supply an explanation.
https://invent.kde.org/plasma/plasma-workspace/-/blob/master/wallpapers/image/plugin/finder/findsymlinktarget.h The plugin already tries to find the original file that a symlink refers to, and will return an empty string when the symlink is too deep.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2209
(In reply to Fushan Wen from comment #4) > https://invent.kde.org/plasma/plasma-workspace/-/blob/master/wallpapers/ > image/plugin/finder/findsymlinktarget.h > > The plugin already tries to find the original file that a symlink refers to, > and will return an empty string when the symlink is too deep. What do you mean by too deep?
(In reply to Duns from comment #6) > What do you mean by too deep? Symlink -> Symlink -> Symlink -> Symlink -> ... -> File
(In reply to Fushan Wen from comment #7) > (In reply to Duns from comment #6) > > What do you mean by too deep? > > Symlink -> Symlink -> Symlink -> Symlink -> ... -> File Uhm... it seems that neither no-deep symlinks work. Or rather, they aren't recognized by the graphical desktop settings window, even, so far, I get now the no-deep symlinks working. I will do some new test. But, why this new rule?
(In reply to Duns from comment #8) > But, why this new rule? It was to fix duplicate images but now that I have a better fix, the bug would be hopefully fixed in 5.26.1
(In reply to Fushan Wen from comment #9) > (In reply to Duns from comment #8) > > But, why this new rule? > > It was to fix duplicate images but now that I have a better fix, the bug > would be hopefully fixed in 5.26.1 It would be wonderful. Thank you very much!
(In reply to Duns from comment #10) > (In reply to Fushan Wen from comment #9) > > (In reply to Duns from comment #8) > > > But, why this new rule? > > > > It was to fix duplicate images but now that I have a better fix, the bug > > would be hopefully fixed in 5.26.1 > > It would be wonderful. Thank you very much! Indeed I noticed also that the new rule is against *every relative* symlink :( Please go back to the previous rule :)
(In reply to Duns from comment #11) > (In reply to Duns from comment #10) > > (In reply to Fushan Wen from comment #9) > > > (In reply to Duns from comment #8) > > > > But, why this new rule? > > > > > > It was to fix duplicate images but now that I have a better fix, the bug > > > would be hopefully fixed in 5.26.1 > > > > It would be wonderful. Thank you very much! > > Indeed I noticed also that the new rule is against *every relative* symlink > :( > Please go back to the previous rule :) Bringing back...
Git commit 28f362dfce3dd065fffcad0eedf7bb87f5235fea by Fushan Wen. Committed on 13/10/2022 at 14:39. Pushed by fusionfuture into branch 'Plasma/5.26'. wallpapers/image: fix symlink not being found by ImageFinder ImageFinder and PackageFinder should not ignore symlinks. FIXED-IN: 5.26.1 M +8 -10 wallpapers/image/plugin/finder/imagefinder.cpp M +4 -6 wallpapers/image/plugin/finder/packagefinder.cpp https://invent.kde.org/plasma/plasma-workspace/commit/28f362dfce3dd065fffcad0eedf7bb87f5235fea
Git commit 21443828ca5f1010bdabf452332917c2768d5d46 by Fushan Wen. Committed on 14/10/2022 at 15:26. Pushed by fusionfuture into branch 'master'. wallpapers/image: fix symlink not being found by ImageFinder Finder uses findSymlinkTarget to find the target file/dir to avoid duplicates, but it forgot to use the target path when collected, so symlinks would still be filtered out. ImageFinder and PackageFinder should not ignore symlinks and this fixes the wrong behavior by using target path from findSymlinkTarget. FIXED-IN: 5.26.1 (cherry picked from commit 28f362dfce3dd065fffcad0eedf7bb87f5235fea) M +8 -10 wallpapers/image/plugin/finder/imagefinder.cpp M +4 -6 wallpapers/image/plugin/finder/packagefinder.cpp https://invent.kde.org/plasma/plasma-workspace/commit/21443828ca5f1010bdabf452332917c2768d5d46
Git commit ac26c89c0de49ff7ae9e0e2a2f3559fcbd7b59af by Fushan Wen. Committed on 14/10/2022 at 15:26. Pushed by fusionfuture into branch 'master'. wallpapers/image: add symlink test M +3 -1 wallpapers/image/plugin/autotests/commontestdata.h M +2 -0 wallpapers/image/plugin/autotests/test_imagefinder.cpp M +2 -0 wallpapers/image/plugin/autotests/test_imagelistmodel.cpp M +3 -0 wallpapers/image/plugin/autotests/test_imageproxymodel.cpp M +2 -0 wallpapers/image/plugin/autotests/test_slidemodel.cpp A +- -- wallpapers/image/plugin/autotests/testdata/default/.BUG460287/BUG460287.webp A +1 -0 wallpapers/image/plugin/autotests/testdata/default/BUG460287.webp https://invent.kde.org/plasma/plasma-workspace/commit/ac26c89c0de49ff7ae9e0e2a2f3559fcbd7b59af
*** Bug 461940 has been marked as a duplicate of this bug. ***
Apparently the fix regressed; re-opening. See Bug 461940.
Likely a different bug. Let's go back to the duplicate