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/#review4186
-----------------------------------------------------------


Thanks Todd for the patch! I agree that the sorting of the filenames should be consistent, however I'm concerned regarding the performance. When introducing the natural sorting for KDE 4.0 I did some profiling in comparison to the default sorting. In the case of Dolphin the decrease of performance was not noticable (if I remember correctly, it was about ~1 % for large lists). I'm against premature optimizations, but in this case I think it is a must to do some profiling first (the split into strings requires at least 4 mallocs + 4 copy operations in the default case for each comparison...). It would already be an improvement to do the split on-thy-fly by using just one QString instance containing one part.

Another note: We may not do the split if no natural sorting is enabled. People who disable the natural sorting expect 1:1 the same sorting as shown in the konsole (I got some very "ambitious" bug reports regarding this topic).


- Peter


On 2010-02-17 00:00:11, Todd wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2988/
> -----------------------------------------------------------
> 
> (Updated 2010-02-17 00:00:11)
> 
> 
> 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
> 
>