Review Request: Consistent file name sorting in the file browser

[Peter Penz]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2988/#review4199
-----------------------------------------------------------


I did some profiling [1] and the updated diff decreases the performance by around 25 %. Sorting is no bottleneck in Dolphin, but after doing some further checks I found out, that KStringHandler::naturalCompare() must be fixed, not KDirSortFilterProxyModelPrivate::compare(). This is good, as it adds no overhead to the performance at all.

I just have added + committed a unittest for bug 201101 (see kdelibs/kdecore/tests/kstringhandlertest.cpp), which fails currently. So for natural sorting, text.txt must be smaller than text1 (natural sorting should just take care that 1 is smaller than 10 etc.), but this is not the case at the moment.

Although the fix should be quite trivial, I don't have the time today to fix this myself. It would be great if you could have a look on this (kdelibs/kdecore/text/kstringhandler.cpp), but of course if you have other topics on your list I'll have a look on this during the next days.

[1] You can use "valgrind --tool=callgrind dolphin --nofork" and check the output file with kcachegrind

- Peter


On 2010-02-18 00:50:19, Todd wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2988/
> -----------------------------------------------------------
> 
> (Updated 2010-02-18 00:50:19)
> 
> 
> Review request for Dolphin and kdelibs.
> 
> 
> Summary
> -------
> 
> In the KDE file manager, there is an inconsistency when sorting by file names when the files have extensions and when they don't.  So, for example, when there is no extension test1 < test1a < test2 < test 10 < test10a < test20.  But when there is an extension you get something like test1a.txt < test1.txt < test2.txt < test10a.txt < test10.txt < test20.txt.  According to the guide that KDE is using for sorting, http://sourcefrog.net/projects/natsort/, the case without extensions is the correct one.  So what this patch does is first compares the filenames without the extension.  If those don't match, it uses that.  If they do match, it compare the extension.  If there are multiple extensions, it compares each extension in sequence.  If the number of extensions do not match, it treats the file with the fewer extensions as having enough empty extensions to make the two files equal.  This fixes the problem without needing any change to the underlying sorting algorithm.s
> 
> 
> This addresses bug 201101.
>     https://bugs.kde.org/show_bug.cgi?id=201101
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdelibs/kfile/kdirsortfilterproxymodel.cpp 1091061 
> 
> Diff: http://reviewboard.kde.org/r/2988/diff
> 
> 
> Testing
> -------
> 
> Tried sorting different combinations of names, extensions, and extension numbers.
> 
> 
> Thanks,
> 
> Todd
> 
>