Review Request: Consistent file name sorting in the file browser

[Peter Penz]

> On 2010-02-21 10:46:57, Peter Penz wrote:
> > I've just tried it and works perfect! Very good: This also bypasses the glibc-locale-aware-compare issue mentioned at bug 181211. Do you haven SVN success already? Otherwise I'll commit the patch for you...
> 
> Todd wrote:
>     Great!  Glad to hear it.  No, I don't have svn access, though, so I would greatly appreciate it if you could commit it.  Thanks!
> 
> Todd wrote:
>     I noticed a new issue.  The problem is that files like "test1 alpha.txt" < "text1.txt" because spaces and punctuation are treated as the same.  Similarly, "test1 alpha" < "test1-test".  I think in most cases I can think of, intuitively spaces would be greater than punctuation.  Would it be alright to add this, so that a place where one string has punctuation and the other has a space the punctuation will win out?
> 
> Peter Penz wrote:
>     > I think in most cases I can think of, intuitively spaces
>     > would be greater than punctuation. 
>     
>     In the unicode table a space is smaller than punctuation and we should stay conform to this (the "natural sorting" should only handle numbers in a special way). However I completely agree that it should not be random whether "test1 alpha.txt" is sorted before "text1.txt" and this should be fixed. Do you think you'd have time for this? Otherwise I'll add this to my TODO list... If you provide a fix, it would be great if you could add a unit test too :-)
> 
> Todd wrote:
>     So, in other words, we should do a specific test for just periods?  What would be the best way to detect a period?

I'm not sure if I understood your question. If your question is regarding the unit test, then I meant just adding your example as test to KStringHandlerTest::naturalCompare() like this:
QCOMPARE(KStringHandler::naturalCompare("test1 alpha.txt", "test1.txt", Qt::CaseSensitive), -1);
QCOMPARE(KStringHandler::naturalCompare("test1.txt", "test1 alpha.txt", Qt::CaseSensitive), +1);


- Peter


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


On 2010-02-19 19:09:07, Todd wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2988/
> -----------------------------------------------------------
> 
> (Updated 2010-02-19 19:09:07)
> 
> 
> 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/kdecore/text/kstringhandler.cpp 1091061 
> 
> Diff: http://reviewboard.kde.org/r/2988/diff
> 
> 
> Testing
> -------
> 
> Tried sorting different combinations of names, extensions, and extension numbers.
> 
> 
> Thanks,
> 
> Todd
> 
>