[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Review Request: Consistent file name sorting in the file browser
From:       "Peter Penz" <peter.penz () gmx ! at>
Date:       2010-02-17 8:00:08
Message-ID: 20100217080008.12418.90115 () localhost
[Download RAW message or body]


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


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
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]