Created attachment 184405 [details] Video of the issue SUMMARY What the title says, I've also attached a video of the issue. STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Sorry for not finishing everything in the first comment, I've clicked enter too soon and it just uploaded the issue without having finished the first comment. SUMMARY Also, as you can see from the video, I can highlight the icon if I move the mouse cursor on top of the icon from the right, top, and left, but if I move it from the bottom it doesn't get highlighted, and this issue doesn't happen on desktop icons that only have one line of text. STEPS TO REPRODUCE 1. Move the cursor from the bottom of a desktop icon with 2 lines of text OBSERVED RESULT The Desktop icon doesn't get highlighted EXPECTED RESULT The Desktop icon gets highlighted SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 42 KDE Plasma Version: 6.4.4 KDE Frameworks Version: 6.17.0 Qt Version: 6.9.1 ADDITIONAL INFORMATION
Can reproduce on Plasma 6.4.4 when moving cursor from wallpaper to icon.
This is already fixed in Plasma 6.5.0, thankfully.
(In reply to Nate Graham from comment #3) > This is already fixed in Plasma 6.5.0, thankfully. thank you! but why doesn't the fix get backported into 6.4.5 too?
It actually may have. I can't quite remember which specific release it went into.
(In reply to Nate Graham from comment #5) > It actually may have. I can't quite remember which specific release it went > into. This issue is still happening in KDE Plasma 6.5.1
In fact it actually got worse now! The desktop icons now don't get highlighted even when I move the cursor from left to right too!
Created attachment 186408 [details] Desktop Icon issue got worse
This specific bug was fixed; the issue you're seeing now is subtly different and tracked with Bug 511025.
(In reply to Nate Graham from comment #9) > This specific bug was fixed; the issue you're seeing now is subtly different > and tracked with Bug 511025. I see that bug has gotten fixed, thanks! Although I'm still experiencing the bug that I've reported in the first post here, where desktop icons with 2 lines of text still don't get highlighted if I hover the mouse cursor on them from the bottom
Yeah, it came back and will be fixed again in Plasma 6.5.4.
(In reply to Nate Graham from comment #11) > Yeah, it came back and will be fixed again in Plasma 6.5.4. ok thanks!
(In reply to Nate Graham from comment #11) > Yeah, it came back and will be fixed again in Plasma 6.5.4. It is still happening in Plasma 6.5.4
I'm acutally testing on KDE Linux with the plasma 6.6 dev version and this issue is happening there also
I'm also on KDE Linux and I can't reproduce the issue. Does it happen for you in a new clean user account on the same computer with only one screen?
(In reply to Nate Graham from comment #16) > I'm also on KDE Linux and I can't reproduce the issue. > > Does it happen for you in a new clean user account on the same computer with > only one screen? yes it happens on a new clean user account on the same computer with only one screen. I'm just talking about the issue where the icon with two lines of text doesn't get highlighted if I move the cursor from the bottom
Right, I can't reproduce it. :/ Any chance you could share a screen recording of it still happening? And what scale factor are you using?
(In reply to Nate Graham from comment #18) > Right, I can't reproduce it. :/ > > Any chance you could share a screen recording of it still happening? > > And what scale factor are you using? Sure! I'm using 100% scaling
Created attachment 187762 [details] Issue still present in KDE Plasma 6.6
I've added the wrong video, sorry
Created attachment 187763 [details] Issue still in KDE 6.6
That's so weird. I can't reproduce it at all. Not with a link, like you've got in the video, and not when the desktop isn't focused; never.
(In reply to Nate Graham from comment #23) > That's so weird. I can't reproduce it at all. Not with a link, like you've > got in the video, and not when the desktop isn't focused; never. I can reproduce it also on my laptop that has an intel igpu, meanwhile my desktop has a nvidia gpu
Created attachment 187807 [details] Issue happening on another system
I clearly see the issue in the screen recording. I'm not able to reproduce the bug on Plasma built from git-master at a couple of different screen resolutions. I also can't reproduce in 6.5.4
Created attachment 187885 [details] Reproducible on KDE Linux 2025-12-22 Can reproduce it on KDE Linux 2025-12-22.
Created attachment 187886 [details] Screen recording - cannot reproduce Screen recording where I try to reproduce the bug
Could it be a nvidia driver bug with qt? I have a 4060 with the 580 driver from fedora
actually not because I can reproduce the issue also on my laptop with an intel igpu, so it can't be just a nvidia issue
Created attachment 187887 [details] diagram showing the areas where hovering triggers It's not a graphics card driver bug, it's a FolderView bug. I can reproduce it and figured out the cause. Consider the attached diagrams. There's two things that fight about what is hovered, the delegate and the overall view. They disagree about when something is hovered. The green lines show the exact areas where the delegates themselves starts to think they're hovered. The blue line shows approximately where the view begins to consider them hovered. As you can see, there's a small gap where the green part goes further than the blue line. If the pointer crosses slowly enough, the delegate will say "hey, I'm hovered now!", the view will say "no you're not", and no hover happens. Then when you move further up, the delegate will say "hey, nothing's changed, all good", and the view is all like "well, I guess you're hovered now, but I don't tell things when they're hovered, I only tell them when they're not hovered, so my job is done". In the end, the mouse is squarely over the icon, but not considered hovered. So as far as I can tell this can only happen - with two-line labels, because otherwise the blue line is always outside the green line - without a row of icons directly below them, as otherwise the green areas directly touch, and then there doesn't seem to be an issue - in that case the green and blue lines are the same - if you move rather slowly over the relevant parts - if you're moving quickly, you might skip the gap completely, and then both immediately agree that they should be hovered. That's why it happens inconsistently. What I don't know yet is - why the blue line is where it is, and not aligning with the blue line - might be a Qt GridView issue, or more likely FolderView is doing something wrong - how to fix this - the best solution would obviously be "don't have several components fight over when one of them is hovered", but that requires cleaning up the logic across several long and very complex files crammed full of arcane and fragile functionality where everything depends on everything else. Long-term something that 100% has to happen, but also a lot of work and it carries the risk of breaking lots of things.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3414
(In reply to Bug Janitor Service from comment #32) > A possibly relevant merge request was started @ > https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3414 thanks!
Thanks cwo, for what it's worth, I compiled your branch (folderview_hover_fix_delegatesize) locally and tested, for me the bug is fixed and so far I could see no problems with folder view widget, desktop icons, other widgets etc.
Git commit 3f7b65e1411ab16b111af59b80141593581a1d0c by Christoph Wolk. Committed on 01/01/2026 at 23:35. Pushed by cwo into branch 'master'. containments/desktop: constrain delegate size by cell size Both the FolderView (parent of the GridView) and the GridView's delegate fight over when icons are hovered. One reason for this is to limit the area that is activating on hover to the actual area covered by the delegate, which may be smaller as the GridView has to handle the case of the delegate having one row of text or two (or even more if the user changed the maximum setting. (Other apps are split about how to handle this; kickoff's grid will activate hover anywhere in the cellSize area, but Dolphin behaves like FolderView here). The problem is that three different ways of calculating the delegate size interact: The delegate itself uses its contentSize which is based on the actual sizes, the GridView internals use the cellSize, and the FolderView's logic for determining hover first uses the cellSize (via the GridView internals) to figure out which item is being hovered, then the actual size to figure out if it's really hovered. More specifically, the delegate checks this on containsMouseChanged, and the FolderView checks on positionChanged. This can only work if the delegate size is never larger than the cellSize - otherwise you can end up in the situation where the delegate thinks it's hovered, the FolderView disagrees (because the first part, mapping the item from its position through the GridView, fails, even if were it to find the correct item, the check for the actual sizes might succeed). If that happens, the delegate won't consider itself hovered again if the user moves the pointer out of the the dead zone fully over the item, as its containsMouse hasn't changed, and the pointer is over the item but the item is not hovered. But the cellSize is an approximation of the actual size using gridUnits for text height, and this approximation is slightly short on multi-line text, causing a dead zone of about three pixels or so. There's several ways to fix this: - ideally, we don't have different components fight over when the delegates are hovered in the first place. But as everything in FolderView depends on everything else (as evidenced by the fact that we have several components fighting over what is hovered), this might involve a long and complicated refactoring of the whole code - still somewhat ideally, we use a better approximation for cellSize. But this likely still wouldn't be perfect and might still cause issues if even the better approximation is wrong. (And there's a bunch of extra logic in there, so everything is not quite straightforward to understand, and fully relying on this seems error-prone). - less ideally, but probably necessary: we don't allow the delegate to ever be larger than the cellSize. Doing that can only cause problems, and the GridView will position items in the next row based on cellSize anyway, so if it's off by more than a few pixels, it'll cover other delegates. (It might still do that anyway with the limited delgate size if the delegate overflows, but there still wouldn't be any benefit to having the delegate be larger, it at best doesn't make things actively worse by itself) This change implements the third option; the second and first can be looked into in the future. FIXED-IN: 6.6.0 M +1 -1 containments/desktop/package/contents/ui/FolderView.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/3f7b65e1411ab16b111af59b80141593581a1d0c
*** Bug 512584 has been marked as a duplicate of this bug. ***
Git commit 9679fdae5f9aa6ca0f59e2f308da4fe94033b137 by Christoph Wolk. Committed on 04/01/2026 at 16:38. Pushed by cwo into branch 'Plasma/6.5'. containments/desktop: constrain delegate size by cell size Both the FolderView (parent of the GridView) and the GridView's delegate fight over when icons are hovered. One reason for this is to limit the area that is activating on hover to the actual area covered by the delegate, which may be smaller as the GridView has to handle the case of the delegate having one row of text or two (or even more if the user changed the maximum setting. (Other apps are split about how to handle this; kickoff's grid will activate hover anywhere in the cellSize area, but Dolphin behaves like FolderView here). The problem is that three different ways of calculating the delegate size interact: The delegate itself uses its contentSize which is based on the actual sizes, the GridView internals use the cellSize, and the FolderView's logic for determining hover first uses the cellSize (via the GridView internals) to figure out which item is being hovered, then the actual size to figure out if it's really hovered. More specifically, the delegate checks this on containsMouseChanged, and the FolderView checks on positionChanged. This can only work if the delegate size is never larger than the cellSize - otherwise you can end up in the situation where the delegate thinks it's hovered, the FolderView disagrees (because the first part, mapping the item from its position through the GridView, fails, even if were it to find the correct item, the check for the actual sizes might succeed). If that happens, the delegate won't consider itself hovered again if the user moves the pointer out of the the dead zone fully over the item, as its containsMouse hasn't changed, and the pointer is over the item but the item is not hovered. But the cellSize is an approximation of the actual size using gridUnits for text height, and this approximation is slightly short on multi-line text, causing a dead zone of about three pixels or so. There's several ways to fix this: - ideally, we don't have different components fight over when the delegates are hovered in the first place. But as everything in FolderView depends on everything else (as evidenced by the fact that we have several components fighting over what is hovered), this might involve a long and complicated refactoring of the whole code - still somewhat ideally, we use a better approximation for cellSize. But this likely still wouldn't be perfect and might still cause issues if even the better approximation is wrong. (And there's a bunch of extra logic in there, so everything is not quite straightforward to understand, and fully relying on this seems error-prone). - less ideally, but probably necessary: we don't allow the delegate to ever be larger than the cellSize. Doing that can only cause problems, and the GridView will position items in the next row based on cellSize anyway, so if it's off by more than a few pixels, it'll cover other delegates. (It might still do that anyway with the limited delgate size if the delegate overflows, but there still wouldn't be any benefit to having the delegate be larger, it at best doesn't make things actively worse by itself) This change implements the third option; the second and first can be looked into in the future. FIXED-IN: 6.6.0 (cherry picked from commit 3f7b65e1411ab16b111af59b80141593581a1d0c) Co-authored-by: Christoph Wolk <cwo.kde@posteo.net> M +1 -1 containments/desktop/package/contents/ui/FolderView.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/9679fdae5f9aa6ca0f59e2f308da4fe94033b137