[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic