SUMMARY This is a possible duplicate of issues 386317, 430177. When setting dolphin to details mode for and sorting the right side tree-view by size folders aren't expanding their contents at the correct position. STEPS TO REPRODUCE 1. Set the file-view to details mode. 2. Sort by size 3. Change to a different folder 4. Expand some of the folders in the file-view OBSERVED RESULT Some of the folders and files contained in the expanded folders (Step 4) will show at wrong positions in the tree-view SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Kernel 6.4.12 KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.109.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION Using NVidia/X11
I can confirm this bug on Dolphin 23.08.0-1 and i think nailed it down to be caused by the amount of items in the folder. Initial situation. Sort is set to Name. i use empty files as items. Folder 1 (2 Items) Folder 2 (1 Item) Folder 3 (3 Items) Folder 4 (4 Items) Now set sort to Size. dolphin seems to sort correctly at first: Folder 2 (1 Item) Folder 1 (2 Items) Folder 3 (3 Items) Folder 4 (4 Items) In this view the folders open as they should. Now refresh (F5). View resets to Initial Situation and Bug is triggered. Now the funny part. Clicking Folder 1 to expand, instead expands Folder 2 and shows content of Folder 1. Took me a second to realize why, but here is the kicker: Increase item amount in Folder 1 to 4 and now Folder 3 (3 items) expands. Increase item amount in Folder 1 to 5 and now Folder 4 (4 items) expands. In other words, always the next smaller folder in item amount is used as "target" a Folder with 2 items expands a folder with 1 item. a Folder with 3 items expands a folder with 2 items. etc. that only works _downwards_ though. e.g. Folder 4 never expands Folder 1, no matter the amount of items.
(In reply to Metz from comment #1) > In other words, always the next smaller folder in item amount is used as Or, it is using the position in the folder list that the clicked folder would be if the sorting by size would show correctly. E.g. Folder 1 with 5 Items would be at the bottom but there is Folder 4 with 4 items (in the wrong view) and it uses that instead.
Created attachment 162355 [details] Folder "flatpak" opened, subfolder below ".git"
Created attachment 162356 [details] Second folder "flutter" opened, subfolder below "docs"
Dolphin 23.08.1 If you open a folder, it is in alphabetical order - it should be by size. This might be the reason for that behavior. Also the opened subfolders aren't preserved, like they are if you use other ordering types. If you sort the folder twice, the order is different and it works as expected. Some folders seem to force a refresh the order and it is working afterwards (like the ".git" folder in my case). I try to upload some recordings of the behavior. One more thing: if you close the folder, the subfolder stays open and you have to refresh. This is a 15-minutes bug for sure.
Created attachment 162357 [details] Ordering twice fixes it - but the open subfolders are not preserved
Created attachment 162358 [details] The subfolder opens at at the wrong spot and can't be closed
*** Bug 430177 has been marked as a duplicate of this bug. ***
*** Bug 386317 has been marked as a duplicate of this bug. ***
Bug 433247 is a duplicate, it was marked as resolved by https://invent.kde.org/system/dolphin/-/merge_requests/232
Can confirm and reproduce the bug on Plasma 6.
It seems the bug happens because the sort order, when created, is thinking that every size count is 0, which leads to alphabetical order. It updates the correct counts later. This then confuses dolphin. The ordering should be done *after* all counting and such is finished.
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/675
*** Bug 471102 has been marked as a duplicate of this bug. ***
Git commit 8f043b2958477d3fe2ef094b7e42f792f4cf0b02 by Méven Car, on behalf of Akseli Lahtinen. Committed on 15/12/2023 at 14:07. Pushed by meven into branch 'master'. Resort directory size count after refreshing After refreshing the view when size count is selected as the sortRole, count is 0 at first. When the actual count is loaded, the sorting is done according to the count being 0. This can break the sort order and cause view and model to be out of sync. Making sure we always resort all items when the directory size/item count is changed fixes this M +7 -0 src/kitemviews/kfileitemmodel.cpp M +2 -0 src/kitemviews/kfileitemmodel.h M +3 -0 src/kitemviews/kfileitemmodelrolesupdater.cpp M +103 -0 src/tests/kfileitemmodeltest.cpp https://invent.kde.org/system/dolphin/-/commit/8f043b2958477d3fe2ef094b7e42f792f4cf0b02
Can you please backport this patch to 5.x LTS versions? This bus quite annoying.
There are no LTS versions of Dolphin, which is an app. There are LTS versions of Plasma, but Dolphin is not on the Plasma release schedule, and also no further releases of Plasma 5 are planned. So I'm afraid you'll have to wait until Dolphin's 24.02 release next month.
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/705
Git commit e817c3246cf512a89a3de003763273f29d9cfe8c by Felix Ernst, on behalf of Felix Ernst. Committed on 23/01/2024 at 12:13. Pushed by felixernst into branch 'master'. Slightly refactor count resorting The bug fix 8f043b2958477d3fe2ef094b7e42f792f4cf0b02 introduced a secondary code path to trigger a resort of items. However, the previous way to trigger it only required a small bug fix to work and gives us a couple of optimisations for free. This commit removes the secondary code path and fixes the primary one. M +3 -2 src/kitemviews/kfileitemmodel.cpp M +2 -2 src/kitemviews/kfileitemmodel.h M +0 -4 src/kitemviews/kfileitemmodelrolesupdater.cpp https://invent.kde.org/system/dolphin/-/commit/e817c3246cf512a89a3de003763273f29d9cfe8c