Version: (using KDE 4.2.96) Create two files: "text.txt" and "text2.txt". You'll notice that Dolphin will put text2.txt before text.txt which may be the correct order my machine standards, but certainly by human expectations.
German language? I don't know who got the idea that Germans want to sort their files that way, it's just a pain to find files with "German" sorting.
*** This bug has been marked as a duplicate of bug 169883 ***
(internal note, as it has been accidentally marked as duplicate to bug 169883: posix ordering is also text2.txt, text.txt, so this wish wants the natural sorting extended to handle "no number" as 0 internally)
Thanks for reopening this bug I just noticed that Dolphin currently also sorts text 2.txt text.txt (see the space there) So this request is for both text.txt text2.txt and text.txt text 2.txt Is this somewhat easy to implement? I hope with the newly implemented feature to disable natural sorting, Peter Paulsen's objections no longer apply.
> Is this somewhat easy to implement? No, it is not easy to get this right + fast... :-( On the other hand fixing this issue might also hide the "wrong locale sorting" issue of Qt, where special characters like -, #, ... or not considered for sorting. I doubt that the "wrong locale sorting" issue in Qt will be fixed (the real root cause is in glibc and the maintainers claim that they are "standard conform" with ignoring the characters).
How about a directory/file sorting cache? Or (as "beta test") a hidden setting via config file editing? Maybe it turns out to be not a huge issue in real world scenarios where >1000 files inside a directory are seldom encountered.
I don't understand all that "new" sorting... For me it is "natural" that "nothing" (= no letter, no cypher, no sign, just the file ending) is less than the cypher zero and less than anything else so e.g. folder.png always should be before any other foldername like folder1.png or folder-1.png because there is nothing behind the last r, it *must* be the first file beginning with "folder", because the name has 5 letters and all other files beginning with the same sequence of letters "folder" have more chars. Is it possible to have this combined with no natural sorting of numbers and combined with ignoring of the file type extension when sorting and ignoring of language specific sorting? Just kind of "telephone book" sorting?
What is language-specific sorting? Roman numbers?
@Markus: > What is language-specific sorting? Roman numbers? It means that e. g. the german 'ü' is after 'u' and not after 'z'. This depends also on the used language and is handled in Qt. @Janet: There is no official definition of "natural sorting" AFAIK. The discussions in the "sorting bug reports" at bugs.kde.org talk about "natural sorting" as defined by the following algorithm: http://sourcefrog.net/projects/natsort The input from Markus is a valid request, but has nothing to do with the "natural sorting" as defined by the http://sourcefrog.net/projects/natsort
(In reply to comment #5) > the real root cause is in > glibc and the maintainers claim that they are "standard conform" with ignoring > the characters). Have you tried contacting the eglibc authors, instead of plain glibc? Debian decided to switch to eglibc for various reasons, one being that attitude by the glibc maintainer. With Debian switching, all derivates (incl Ubuntu) will switch, too. What about other platforms? FreeBSD, Windows, etc. don't use glibc. While I use Linux, my request is not limited to Linux only. :-) (In reply to comment #9) > It means that e. g. the german 'ü' is after 'u' and not after 'z'. > This depends also on the used language That sounds just wrong. Why should the Romanian letter ă be sorted after z, but ä after a, just because I use German and not Romanian locale setting? An a with any diacritic sign should be located among a, not after z. I really don't think that Japanese users see that any different.
> Have you tried contacting the eglibc authors, instead of plain glibc? This is in the responsibility of Qt Software, there is nothing I can do on this topic. > What about other platforms? FreeBSD, Windows, etc. don't > use glibc. While I use Linux, my request is not limited to Linux only. :-) AFAIK Qt only uses glibc for this task on Linux, so on other platforms this issue does not occur. > That sounds just wrong. No, this is correct. See http://msdn.microsoft.com/en-us/library/aa292178%28VS.71%29.aspx (section "String Sorting and Comparison") or http://stackoverflow.com/questions/127913/sorting-strings-is-much-harder-than-you-thought. Example from link #2: "In German, 'Ä' often comes at the beginning of the alphabet, whereas in Swedish it's towards the end."
> The input from Markus is a valid request, and a very good one, I completely agree with: text.txt should always be before any other text something.txt! That's what for me is "natural": you have a four letter word and a file extension. When you have "text .txt" you have a five "letter" word starting with the same four letters so it should be sorted behind the four letter word. A space is more than nothing so a word with a following space comes after the word with nothing behind it.
I don't know if it is related... but I found another natural stupid way of sorting in dolphin. I have 4 files: k.cpp ,kgui.cpp kgui.h, k.h and the sorting is done like this: k.cpp kgui.cpp kgui.h k.h Apparently the 'g' is ahead of 'h' as the '.' is ignored... naturally stupid.
@manolis: I agree, this sorting is stupid. But as mentioned in comment #11 this is done inside Qt... I'm thinking of bypassing this issue in kdelibs, but I doubt I can do this until KDE 4.4.
@ Peter Penz: "The input from Markus is a valid request, but has nothing to do with the "natural sorting" as defined by the http://sourcefrog.net/projects/natsort" According to that link, a < a0 < a1 < a1a < a1b < a2 < a10 < a20 That seems to be exactly what this bug report is all about. That works if files don't have extensions, but if you add extensions you get this: a0.txt < a1a.txt < a1b.txt < a1.txt < a2.txt < a10.txt < a20.txt < a.txt The order of sorting of these files is totally different than the order listed in the link you provided. Now granted the files have extension while the ordering on the website doesn't, but I do think it is a valid point that, ignoring the extension, the sorting should be the same as it is on the website you provided.
The way dolphing sorts files and directories is IMHO unpredictable. AFAICS dolphin checks if a file/directory name evaluates to a numerical expression (eg. "20100103"), if so, sort by the numeric value. This seems to be a good idea, but is isn't, as the following is the dolphin-sorted order of a directory containing subdirectories: 1999 2007 199910 200908 19991010 20040526 20071024 The IMHO correct sorting (as displayed via ls -1) is: 1999 199910 19991010 20040526 2007 20071024 200908 20091001 Now, for more fun with dolphin sorting let's see how a bunch of MD5 hashes are sorted (a real life example, consider you'll have to find a certain file with a given MD5 hash in a directory containing some hundreds MD5 hashes gives you an impression how useful the current dolphin sorting is). The numeric sort interferes if parts of the MD5 could be interpreted as a decimal number, resulting in the following sort order: 0E798DEA6AFD3AB5344C9F9B912845D0 04420B8D290F937D88D569FC7C57853A 1A2A355A6655E32600974C8F4036FD74 88BEBEF0CBEFFCDBF89F9BB2A0DE4A13 116D41E214B4A03B4B5AA4D9D469FFD6 951A811DDA02ABAF2AB5922100F04BD5 1315A4A45DF9F94D80C71DDA64875435 8513D6CF82299817CCC59F49EB1C5F41 25143A3ECE08556533C318B75269F1D1 Again, ls -1 displays the correct order: 04420B8D290F937D88D569FC7C57853A 0E798DEA6AFD3AB5344C9F9B912845D0 116D41E214B4A03B4B5AA4D9D469FFD6 1315A4A45DF9F94D80C71DDA64875435 1A2A355A6655E32600974C8F4036FD74 25143A3ECE08556533C318B75269F1D1 8513D6CF82299817CCC59F49EB1C5F41 88BEBEF0CBEFFCDBF89F9BB2A0DE4A13 951A811DDA02ABAF2AB5922100F04BD5
@Jo: This has been fixed in Dolphin for KDE SC 4.4.0. An option is available to have the sorting you'd like (-> exact the same sorting as ls -l). But this is unrelated to the original bugreport, which wants text.txt sorted before text2.txt.
SVN commit 1093884 by ppenz: Fix sorting issues of bugs 181211 and 201101. Thanks to Todd for the patch! BUG: 201101 BUG: 181211 CCMAIL: toddrme2178@gmail.com M +11 -2 kstringhandler.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1093884
SVN commit 1093886 by ppenz: Backport of SVN commit 1093884 (should be part of KDE SC 4.4.1): Fix sorting issues of bugs 181211 and 201101. Thanks to Todd for the patch! CCBUG: 201101 CCBUG: 181211 CCMAIL: toddrme2178@gmail.com M +11 -2 kstringhandler.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1093886