Bug 490677

Any chance you could attach a screen recording that shows the issue happening? I'm having a hard time both reproducing the issue and also even visualizing what it would look like.

Created attachment 172044 [details]
Normal folderview appearance

What view loos like normally.  It may or may not hav one item highlighted.

Created attachment 172046 [details]
After long click

After long click then moving mouse out the bottom of the view

Created attachment 172048 [details]
After moving mouse in then  out

This time I moved the cursor into the view, moved it around a bit, them moved the mousse out the top.

Note that while the cursor is inside the view, the highlight rectangle changes shape centered arund where the cursor entered the view.

Note the retangle size difference between this screenshot and the previous.

Created attachment 172049 [details]
After click out

This is after clicking outside the view then moving the cursor into the view then out.

Again, as long as the cursor remains inside the view the rectangle changes size as the cursor is moved around the entry point.

Created attachment 172050 [details]
After clickout and moving mcursor in then out of view

Same as last, but pointing out that the size of the rectangle changes until the cursor leaves the view.

Created attachment 172051 [details]
After click out then click in

In this case I had the selection rectangle around four items.  I didn't investigate very far, but only one of the items that was selected and so clicking on execute open one of the folders in dolphin.  I did not try to find a pattern on which is opened, except that only one did open.

Created attachment 172052 [details]
After clickout then mouse in and click

This is what the folder view looks like after click in the view and the previous screenshots dialog pops up.  Closing the pop up leaves the view as this screenshot depicts.

Thanks. I can't reproduce any of those issues, and your screenshots are a bit weird, with scaling glitches that look like they should only be seen on X11. Were they taken in an X11 session, or on Wayland with the font DPI manually forced to some value instead of using the scaling system?

Can you reproduce this in a new clean user account with no customization in a wayland session (except adding a Folder View widget to the desktop, of course)?

If so, can you comment on what hardware you're using?

Never mind, I just reproduced it. I think I understand how I wasn't able to reproduce it in the past. It on'y happens when the final row in the grid isn't fully filled up with files or folders.

(In reply to Nate Graham from comment #9)
> Thanks. I can't reproduce any of those issues, and your screenshots are a
> bit weird, with scaling glitches that look like they should only be seen on
> X11. Were they taken in an X11 session, or on Wayland with the font DPI
> manually forced to some value instead of using the scaling system?
> 
> Can you reproduce this in a new clean user account with no customization in
> a wayland session (except adding a Folder View widget to the desktop, of
> course)?
> 
> If so, can you comment on what hardware you're using?

32" monitor, 3840x2160 resolution.  No scaling.  I do an the system fonts set to 21 or 22.

Wayland or X11, it doen't matter.

What you are seeing are screenshnots on only the Folder view, not of the entier screen.

(In reply to Nate Graham from comment #10)
> Never mind, I just reproduced it. I think I understand how I wasn't able to
> reproduce it in the past. It on'y happens when the final row in the grid
> isn't fully filled up with files or folders.

It happens for me no matter how many icons are in the view.    I am will ing to have a zoom session to demonstrate.

I can only reproduce it when the final row isn't filled up, but it doesn't matter; fixing that will fix it universally.

FWIW I would recommend setting the system to 200% scale rather than doubling the font size. Everything will look a lot better, and you won't have tiny icons and weird visual glitches everywhere.

Using scaling would only migate the advantages of a large screen.  I tried it once some years ago and found it to be pretty awful.  But thanls for the suggestion.

And now that I found out how to increase icon size, I am happy again.  I am even finding that wayland is up to snuff.  At least for my use case.

You're welcome. FWIW making icons and text twice as large at 100% scale pretty much gets you 90% of the way to just using the global scaling system, just with random visual glitches all over the place, and the size relationships between objects broken. You might try it again on Wayland. We've put a lot of work into making the scaling system work nicely.

The real problem with scaling is that it makes everything bigger and so everghing takes up more screen real estate.

And besides, I've have my desktop set up how I like it for a very long time.  Since KDE 3 :-)

*** Bug 509859 has been marked as a duplicate of this bug. ***

Git commit 28aede3a7d55fdbec8c5d23f4959404b0ddd69f1 by Akseli Lahtinen.
Committed on 26/09/2025 at 08:49.
Pushed by akselmo into branch 'master'.

FolderView: Use let instead of var, check for item existence

We should use let keyword here instead of var, since
var is scoped to whole function, while let is scoped to blocks.

This would cause the itemX and itemY grow indefinitely in some cases.

Check also for item existing before trying to check intersection to
avoid warning log spam.

M  +19   -18   containments/desktop/package/contents/ui/FolderView.qml

https://invent.kde.org/plasma/plasma-desktop/-/commit/28aede3a7d55fdbec8c5d23f4959404b0ddd69f1

Git commit df8ffdb3c9bf43d16ae8d8e87061744abbb9b3f6 by Akseli Lahtinen.
Committed on 26/09/2025 at 08:49.
Pushed by akselmo into branch 'master'.

FolderView: Clear press state when applet is disabled

When user starts to drag and move the folderview applet, it gets
disabled.
This can cause the rubberband to appear due to the rubberband being
created just before the folderview gets disabled.

Make sure we always clear the press state when the applet
is disabled, so it's in normal state after enabled is
turned back on again.

M  +6    -0    containments/desktop/package/contents/ui/FolderView.qml

https://invent.kde.org/plasma/plasma-desktop/-/commit/df8ffdb3c9bf43d16ae8d8e87061744abbb9b3f6

Git commit 88bd17fb2987492ddb3e3042292932f27d807dc7 by Akseli Lahtinen.
Committed on 26/09/2025 at 10:48.
Pushed by akselmo into branch 'Plasma/6.5'.

FolderView: Use let instead of var, check for item existence

We should use let keyword here instead of var, since
var is scoped to whole function, while let is scoped to blocks.

This would cause the itemX and itemY grow indefinitely in some cases.

Check also for item existing before trying to check intersection to
avoid warning log spam.
(cherry picked from commit 28aede3a7d55fdbec8c5d23f4959404b0ddd69f1)

M  +19   -18   containments/desktop/package/contents/ui/FolderView.qml

https://invent.kde.org/plasma/plasma-desktop/-/commit/88bd17fb2987492ddb3e3042292932f27d807dc7

Git commit eaa36db3c3da2214651d9c27e909fd4ee68393eb by Akseli Lahtinen.
Committed on 26/09/2025 at 10:48.
Pushed by akselmo into branch 'Plasma/6.5'.

FolderView: Clear press state when applet is disabled

When user starts to drag and move the folderview applet, it gets
disabled.
This can cause the rubberband to appear due to the rubberband being
created just before the folderview gets disabled.

Make sure we always clear the press state when the applet
is disabled, so it's in normal state after enabled is
turned back on again.
(cherry picked from commit df8ffdb3c9bf43d16ae8d8e87061744abbb9b3f6)

M  +6    -0    containments/desktop/package/contents/ui/FolderView.qml

https://invent.kde.org/plasma/plasma-desktop/-/commit/eaa36db3c3da2214651d9c27e909fd4ee68393eb