STEPS TO REPRODUCE 1. have icons on desktop 2. align the icons on desktop to right 3. click on any icon on desktop OBSERVED RESULT nothing happens EXPECTED RESULT the click has effect SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 6.2.80 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.1 Graphics Platform: Wayland
I can sort of reproduce it. with right alignment, if I move the pointer from right to left, items don't highlight, and don't respond to click. The moment I move the pointer at all from left to right, items start highlighting again and will begin responding to clicks. Can you reproduce this, Patrick?
I can't reproduce, Nate. On my system, the icons are not highlighted and clicks have no effect regardless of the direction of mouse movement.
That's pretty odd. Any chance you can attach a screen recording? Does it make a difference if you set the alignment using the config window vs the desktop context menu?
Created attachment 176693 [details] screen recording No difference between config window and desktop context menu.
I'm not able to reproduce either the unresponsive icons -or- non-highlight with right to left pointer movement with *just* Icons - Align - Right. With that setting, mouse clicks and drag on icons works normally I am able to reproduce the bug if I then set Icons - Arrange - Top to Bottom I see the same behavior as in the screen recording. There's that brief flash of an outline and the up arrow as I move the cursor across an icon Clicking on any icon does nothing If I switch icons - Arrange back to Left to Right, they behave normally again SOFTWARE/OS VERSIONS Operating System: Solus Plasma KDE Plasma Version: 6.2.80 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.1 Graphics Platform: Wayland I'm going to build a neon unstable VM and test there In the meantime, Patrick, do you have any other settings applied to the desktop icons aside from
If I have arrangement "left to right" the icons get highlighted when i approach them with cursor from left. But if i approach from right, they wont get highlighted. Something is wrong with the icon grid model most likely.
(In reply to Akseli Lahtinen from comment #6) > If I have arrangement "left to right" the icons get highlighted when i > approach them with cursor from left. But if i approach from right, they wont > get highlighted. > > Something is wrong with the icon grid model most likely. I can reproduce that issue when "Arrange" is set to "left to right". If I set it to "top to bottom", then I get the worse issue that Patrick and Tracey are encountering.
I managed to reproduce it on a simple Qt test case, it seems an actual Qt bug: https://bugreports.qt.io/browse/QTBUG-132798
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2723
Git commit 509b655ef2edef04a13d9afaab6349911beaaeb1 by Marco Martin. Committed on 15/01/2025 at 12:19. Pushed by mart into branch 'master'. containments/desktop: properly map position to find the mouseover item GridView.itemAt() is documented to accept coordinated in *contentItem* coordinates. passing coordinates in view coordinates will cause items to not be found if contentItem position is not 0,0 With right align, the contentItem is aligned to the right edge of the view and items are positioned from there at negative x coordinates. M +2 -1 containments/desktop/package/contents/ui/FolderView.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/509b655ef2edef04a13d9afaab6349911beaaeb1
Git commit 362e4c7027bbf9eee931235d7ec652b6900d0d95 by Marco Martin. Committed on 15/01/2025 at 12:37. Pushed by mart into branch 'Plasma/6.3'. containments/desktop: properly map position to find the mouseover item GridView.itemAt() is documented to accept coordinated in *contentItem* coordinates. passing coordinates in view coordinates will cause items to not be found if contentItem position is not 0,0 With right align, the contentItem is aligned to the right edge of the view and items are positioned from there at negative x coordinates. (cherry picked from commit 509b655ef2edef04a13d9afaab6349911beaaeb1) 509b655e containments/desktop: properly map position to find the mouseover item Co-authored-by: Marco Martin <notmart@gmail.com> M +2 -1 containments/desktop/package/contents/ui/FolderView.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/362e4c7027bbf9eee931235d7ec652b6900d0d95
*** Bug 499446 has been marked as a duplicate of this bug. ***
*** Bug 499493 has been marked as a duplicate of this bug. ***
Can reproduce again on Plasma 6.4 beta 2. Operating System: Arch Linux KDE Plasma Version: 6.3.91 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.1 Graphics Platform: Wayland
Can reproduce. Seems bad.
This was caused by the same change that caused Bug 505718: commit 53d67b9a0b82fff40b2057f1ceb74b529b943df5 (HEAD) Author: Christoph Wolk <cwo.kde@posteo.net> Date: Mon May 26 12:17:04 2025 +0200 containments/desktop: redetermine item on click In case of touch events, Folder View already resets the hovered item to the actual click position, as touch does not cause hover events. There is another case where a click on a non-hovered element can happen, namely if the containsMouse determination is blocked by an open context menu. If the user does not move the pointer after opening a context menu, moving the pointer to another item, and closing the context menu, left-clicking will leave the icon completely unaffected and right- clicking will re-open the previous context menu, rather than open the one for the clicked entry. Instead, always take the delegate that was clicked to activate or open the context menu, whether on touch or not. This matches the behavior in Dolphin, where in the same situation the hover feedback is not updated, but clicking still works normally. BUG: 504765 containments/desktop/package/contents/ui/FolderView.qml | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-)
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3075
Git commit dbd2551e3097433b838facf4045c67427069a581 by Christoph Wolk. Committed on 20/06/2025 at 16:25. Pushed by cwo into branch 'master'. containments/desktop: fix folder view clicking 53d67b9a0b82fff40b2057f1ceb74b529b943df5 made clicking use the same logic to determine the selected item for mouse and touch, rather than relying on hover events. It seems the logic for touch was broken in some cirumstances, namely scrolled views and certain alignments, where the coordinate systems do not align. A similar issue was already fixed elsewhere in folder view with 509b655ef2edef04a13d9afaab6349911beaaeb1, so we reuse the approach here. Related: bug 505718, bug 504569 FIXED-IN: 6.4.1 ---- Would be good if someone could test if this works with touch, as I don't have a functional touch device handy. Might be that this was also broken there (couldn't find a bug report there though) or doesn't apply. M +2 -1 containments/desktop/package/contents/ui/FolderView.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/dbd2551e3097433b838facf4045c67427069a581
Git commit f6c6e03a5fed3435ea47605e232af57140625440 by Christoph Wolk. Committed on 20/06/2025 at 16:25. Pushed by cwo into branch 'Plasma/6.4'. containments/desktop: fix folder view clicking 53d67b9a0b82fff40b2057f1ceb74b529b943df5 made clicking use the same logic to determine the selected item for mouse and touch, rather than relying on hover events. It seems the logic for touch was broken in some cirumstances, namely scrolled views and certain alignments, where the coordinate systems do not align. A similar issue was already fixed elsewhere in folder view with 509b655ef2edef04a13d9afaab6349911beaaeb1, so we reuse the approach here. Related: bug 505718, bug 504569 FIXED-IN: 6.4.1 ---- Would be good if someone could test if this works with touch, as I don't have a functional touch device handy. Might be that this was also broken there (couldn't find a bug report there though) or doesn't apply. (cherry picked from commit dbd2551e3097433b838facf4045c67427069a581) 4445acf7 containments/desktop: fix folder view clicking Co-authored-by: Christoph Wolk <cwo.kde@posteo.net> M +2 -1 containments/desktop/package/contents/ui/FolderView.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/f6c6e03a5fed3435ea47605e232af57140625440
Just confirming that I tested this on a touchscreen laptop and verified the bug is fixed
*** Bug 505952 has been marked as a duplicate of this bug. ***
*** Bug 505860 has been marked as a duplicate of this bug. ***
*** Bug 506515 has been marked as a duplicate of this bug. ***