SUMMARY Generically, a drag of a tree node or a tag node etc in the tree works as it should- select, drag up or down, and if you approach top or bottom of the control window, the window scrolls continuously. In Thumbnail mode, where if you have say 2 images that you want to group via a drag-over, and where those images are separated whatever- 50 other images due to naming or sorting preference etc- a drag of a file to the control boundary yield a nudge in that direction, but not a scroll. So, you have to back off and move down again. The nudges are tiny- 10 pixels etc, so moving a full row can take 50 cycles, and multiple rows- forget it. Easier to create a subfolder, move the files there, group them, and move them back to the parent folder. STEPS TO REPRODUCE 1. In Thumbnail view, find a folder that has enough images to yield something like 3+ pages of images 2. Select any image from any row on the first page of thumbnails, and commence a drag op towards any image on the 3rd+ page 3. As you approach the frame's bottom boundary, you will see the images on page 1 nudge up a bit and stop. OBSERVED RESULT As with #3 above, page nudges up, but doesnt move continuously EXPECTED RESULT Page should scroll up, as is typical with any file manager, since doing a mouse-click-drag on the scroll bar control by defintion is not compatible with holding a selected image in drag mode 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 Its possible this is some user setting/config thing, but if it is, I cannot imagine any scenario where this would be beneficial. And, its not consistent with how the Album or tag trees work, or how file managers/explorer work.
Can you record a screencast of your desktop to see exactly the dysfunction here. This will help to investigate.
The zone where scrolling begins is currently 16 pixels. We cannot change the speed; a bug report exists regarding this. It is important that the mouse cursor is not moved within this zone. The speed increases but immediately slows down if the cursor moves even one pixel. Maik
Created attachment 188670 [details] demo of drag scroll failure
Yes, I can confirm this problem under Windows. Maik
Git commit ce13c4c5623013d2835564f3ae4333f5784bda2a by Maik Qualmann. Committed on 19/01/2026 at 15:50. Pushed by mqualmann into branch 'master'. try fix auto scroll QListView on Windows setAcceptDrops(true) is already correctly set in the ItemCategorizedView at the viewport(). M +1 -1 core/app/items/views/digikamitemview.cpp https://invent.kde.org/graphics/digikam/-/commit/ce13c4c5623013d2835564f3ae4333f5784bda2a
And i can confirm also the dysfunction under Linux with Qt6, but not under macOS. Gilles
The commit do not fix the problem under Linux
Git commit 495b4d59d2cfe15648e5dcf338a982aeb5929230 by Maik Qualmann. Committed on 19/01/2026 at 19:01. Pushed by mqualmann into branch 'master'. next try to fix QListView auto scroll M +3 -0 core/app/items/views/digikamitemview.cpp M +4 -4 core/libs/widgets/itemview/itemviewcategorized.cpp https://invent.kde.org/graphics/digikam/-/commit/495b4d59d2cfe15648e5dcf338a982aeb5929230
I don't have this problem under Linux, neither under X11 nor under Wayland. Maik
Based on this weblog, it also shows a way to change the scroll speed. https://runebook.dev/en/docs/qt/qabstractitemview/autoScroll-prop Maik
Same behavior under Linux. I need to vibe the mouse a little bit over the drag area (on the top or bottom of the icon-view), else the scroll do not work. Gilles