Version: 1.3 (using 4.3.4 (KDE 4.3.4), Gentoo)
OS: Linux (x86_64) release 2.6.31-gentoo-r6
The reproduction steps:
- Create two folders which names are different only in case. For example: "new_folder" and "New_folder".
- Place an image file or some into them both.
- Open Dolphin in the parent folder and enable preview mode.
- Move mouse cursor to the folder icon placed first and wait a bit, it will move down, the second folder appears at the first place. Move cursor again, they will be switched again.
- Move cursor above the second folder icon. The first and second will switches fast.
The same is for image files. Image.png and image.png, for example.
Sorry for my English. Hope you understand me =))
Thanks for the report, but I cannot reproduce the issue (KDE 4.3.3). Is this issue really related to case sensitivity of the file names? This would be quite strange, as in the Dolphin and kdelibs code the comparison are always done case sensitive... Would it be possible that you zip a small test folder and attach it to this bug report? Maybe it is related to a .directory setting in your folder... Thanks :-)
Created attachment 38793 [details]
archive contains the test folder with two images inside.
Unpack this archive and go into the test folder. Try to reproduce the bug with images inside.
Also one note. My folder view settings are configured to use common view properties for all folders, so problem is not in .directory, i think.
Peter, in case you still can't reproduce the issue, please check https://bugs.kde.org/show_bug.cgi?id=194981#c1 for another approach
*** Bug 212452 has been marked as a duplicate of this bug. ***
*** Bug 221991 has been marked as a duplicate of this bug. ***
*** Bug 236517 has been marked as a duplicate of this bug. ***
I think I know what's going on: In principle, file sorting is case insensitive, which means that the sort order of "1.PNG" and "1.png" will be random. If an item is hovered with the mouse, KFilePreviewGenerator will call the model's setData() method, which causes a resorting (see backtrace below). The resorting may result in a different sort order.
One way to fix this would be to change KDirSortFilterProxyModel::KDirSortFilterProxyModelPrivate::compare() such that a case sensitive comparison is done if the case insensitive comparison yields "equal". The sort order would always be well-defined then.
@Peter: what do you think?
Breakpoint 1, DolphinSortFilterProxyModel::subSortLessThan (this=0x9afd40, left=..., right=...) at /home/kde-devel/kde/src/KDE/kdebase/apps/dolphin/src/dolphinsortfilterproxymodel.cpp:115
#0 DolphinSortFilterProxyModel::subSortLessThan (this=0x9afd40, left=..., right=...) at /home/kde-devel/kde/src/KDE/kdebase/apps/dolphin/src/dolphinsortfilterproxymodel.cpp:115
#1 0x00007ffff642fb74 in KCategorizedSortFilterProxyModel::lessThan (this=0x9afd40, left=..., right=...) at /home/kde-devel/kde/src/KDE/kdelibs/kdeui/itemviews/kcategorizedsortfilterproxymodel.cpp:119
#2 0x00007ffff59071d4 in QSortFilterProxyModelPrivate::proxy_intervals_for_source_items_to_add (this=0x9b0880, proxy_to_source=..., source_items=..., source_parent=..., orient=Vertical)
#3 0x00007ffff5907802 in QSortFilterProxyModelPrivate::insert_source_items (this=0x9b0880, source_to_proxy=..., proxy_to_source=..., source_items=..., source_parent=..., orient=Vertical, emit_signal=false)
#4 0x00007ffff5909b44 in QSortFilterProxyModelPrivate::_q_sourceDataChanged (this=0x9b0880, source_top_left=..., source_bottom_right=...) at itemviews/qsortfilterproxymodel.cpp:1126
#5 0x00007ffff590e99d in QSortFilterProxyModel::qt_metacall (this=0x9afd40, _c=InvokeMetaMethod, _id=5, _a=0x7fffffffc6b0) at .moc/debug-shared/moc_qsortfilterproxymodel.cpp:128
#6 0x00007ffff712da5d in KDirSortFilterProxyModel::qt_metacall (this=0x9afd40, _c=InvokeMetaMethod, _id=30, _a=0x7fffffffc6b0) at /home/kde-devel/kde/build/KDE/kdelibs/kfile/kdirsortfilterproxymodel.moc:68
#7 0x00007ffff763d501 in DolphinSortFilterProxyModel::qt_metacall (this=0x9afd40, _c=InvokeMetaMethod, _id=30, _a=0x7fffffffc6b0)
#8 0x00007ffff3e7859d in QMetaObject::metacall (object=0x9afd40, cl=InvokeMetaMethod, idx=30, argv=0x7fffffffc6b0) at kernel/qmetaobject.cpp:237
#9 0x00007ffff3e8ec2e in QMetaObject::activate (sender=0x9af9a0, m=0x7ffff41ed3c0, local_signal_index=0, argv=0x7fffffffc6b0) at kernel/qobject.cpp:3291
#10 0x00007ffff3ef64b1 in QAbstractItemModel::dataChanged (this=0x9af9a0, _t1=..., _t2=...) at .moc/debug-shared/moc_qabstractitemmodel.cpp:148
#11 0x00007ffff6a6ab39 in KDirModel::setData (this=0x9af9a0, index=..., value=..., role=1) at /home/kde-devel/kde/src/KDE/kdelibs/kio/kio/kdirmodel.cpp:803
#12 0x00007ffff76395a7 in DolphinModel::setData (this=0x9af9a0, index=..., value=..., role=1) at /home/kde-devel/kde/src/KDE/kdebase/apps/dolphin/src/dolphinmodel.cpp:78
#13 0x00007ffff715c15b in KFilePreviewGenerator::Private::dispatchIconUpdateQueue (this=0x9bd7c0) at /home/kde-devel/kde/src/KDE/kdelibs/kfile/kfilepreviewgenerator.cpp:701
#14 0x00007ffff715ef64 in KFilePreviewGenerator::qt_metacall (this=0x9bb800, _c=InvokeMetaMethod, _id=5, _a=0x9d8170) at /home/kde-devel/kde/build/KDE/kdelibs/kfile/kfilepreviewgenerator.moc:98
@Frank: I agree, in this case we need a deterministic behavior. I've marked this issue as TODO for SC 4.5 (I've just recently fixed another related sorted issue and I hope that this fix should be rather trivial).
SVN commit 1127780 by ppenz:
If a case insensitive comparison is done and the strings are equal, a case sensitive comparison must be done as fallback to have a deterministic sorting order. Otherwise it is possible that items "toggle" during hovering.
M +14 -3 kdirsortfilterproxymodel.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=1127780
SVN commit 1127782 by ppenz:
Backport of SVN commit 1127780: If a case insensitive comparison is done and the strings are equal, a case sensitive comparison must be done as fallback to have a deterministic sorting order. Otherwise it is possible that items "toggle" during hovering.
M +14 -3 kdirsortfilterproxymodel.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=1127782
*** Bug 237788 has been marked as a duplicate of this bug. ***
Thank you, guys! The bug has gone in 4.5 beta1.
Well it doesn't seem to be fixed. Same problem here with KDE 4.5.1, dolphin 1.5, files are permanently reordered so that I cannot select the right one.
The files that are fooling me just now by constant evading and resorting are:
pict9209_Susanne_org.jpg, pict9209_susanne.xcf, pict9209_susanne1.jpg and pict9209_susanne2.jpg. By default pict9209_susanne1.jpg is the first file, followed (why?) by pict9209_susanne.xcf, followed by pict9209_susanne2.jpg and the last one pict9209_Susanne_org.jpg. As soon as I want to select one, the order switches to pict9209_Susanne_org.jpg first, or the xcf first - dolphin likes playing tricks as it seems...
Janet, could you file a new bug report about the issue? I think it might be better to start a clean bug report because the issue which was originally reported here seems to be fixed. BTW, I've created 4 files with the names you mentioned and did not get a reordering. I checked today's trunk and 4.5 branch with "Sort by Name".
Janet, I also could not reproduce the issue with 4.5.1. The sort order is always:
Selecting a file does not change the order (tested with icons + details-view)
Strange. Still drives me nuts here. All the four files (pict9209_Susanne_org.jpg with two n, one small s)) fight for the leading position. I wonder if I have some special settings. Icon or details view with thumbnails on or off (does not matter), natural sorting enabled.
When I enter the folder it looks ok. Until my mouse touches one of the mentioned files. Then, after a short delay, they begin to change positions when I insist on touching one.
It also happens when I rename the file with the upper case S to lower case.
The spook settles when I insert a "3" in the filename between "susanne" and "_org": pict9209_susanne3_org.jpg. It begins again as soon as I insert a "_" directly after "susanne" in one of the files. It stops again when I insert a "_" after "susanne" in all files.
Maybe it conflicts with LC_COLLATE=C?