> On Sept. 18, 2013, 3:22 p.m., Mark Gaiser wrote: > > How RUDE to just commit this without a addressing the concerns Frank and i > > have. That is not appreciated! > > Aleix Pol Gonzalez wrote: > Alright, maybe I didn't think this through. I'll un-deprecate and bring > back the KStringHandler::naturalCompare code as you want. > > Said that, I doubt these concerns make that much a difference. QCollator > has to be adopted. Not because of performance reasons but localization alone. > Performance will happen as well, but for that we need development on the > applications side, which I'm afraid cannot be up to me as well. > > Either way, if you really shouldn't consider ::naturalCompare as a > solution. ICU is much better tested than naturalCompare (yes, even) and has > people more qualified than us by making it locale aware (::naturalCompare > implementation is naive to localization). > > Mark Gaiser wrote: > Idea: restore naturalCompare as it was and add a "collatorNaturalCompare" > that is taking the QCollator route. That way it's easily testable as well.
See the other patch I just sent. I don't think creating such function would be a good thing because it means using QCollator the wrong way. I much rather prefer working on tools to properly use QCollator, for example by making it possible to sort things with the sort key instead of QCollator::compare. - Aleix ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112717/#review40277 ----------------------------------------------------------- On Sept. 18, 2013, 2:58 p.m., Aleix Pol Gonzalez wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/112717/ > ----------------------------------------------------------- > > (Updated Sept. 18, 2013, 2:58 p.m.) > > > Review request for KDE Frameworks, Frank Reininghaus and Aurélien Gâteau. > > > Description > ------- > > Now that QCollator is public API, I wanted to give it a try, so I decided to > port all uses KStringHandler::naturalCompare() to QCollator. > > All the porting was quite straightforward I'd say, the only weird part is > that I removed some tests of the KStringHandler tests. There are 2 kind of > tests disabled: > - The ones that say that "A" == "a" in case of Qt::CaseInsensitive. ICU is > deterministic and it will decide itself which one goes in, so the test > doesn't make sense anymore. > - There's a mention to the 237788 bug where in some cases our former > algorithm wouldn't be deterministic. This doesn't apply anymore, but also now > ICU takes care about it now, so there's little point of keeping unit testing > it. > I decided to leave the unit test because it might be useful eventually > (although note that it was not being compiled so far). In any case we > probably want it out. > > In any case, the rest seems straightforward enough. I didn't concentrate on > performance though, in some cases we'll want to use the QCollatorSortKey. > > > Diffs > ----- > > KDE5PORTING.html 1287de7 > kfile/kdirsortfilterproxymodel.cpp 7c7aa5f > kfile/kurlnavigatorbutton.cpp d2c27fd > staging/itemviews/src/CMakeLists.txt 353a413 > staging/itemviews/src/kcategorizedsortfilterproxymodel.h a21e7ca > staging/itemviews/src/kcategorizedsortfilterproxymodel.cpp c8b652d > staging/itemviews/src/kcategorizedsortfilterproxymodel_p.h eb1a67b > staging/kcompletion/src/kcompletion.cpp 5f60a6c > staging/xmlgui/src/kshortcutsdialog_p.h ab102bc > staging/xmlgui/src/kshortcutseditoritem.cpp e89a8aa > tier1/kcoreaddons/autotests/CMakeLists.txt 19227dc > tier1/kcoreaddons/autotests/kstringhandlertest.cpp d12f086 > tier1/kcoreaddons/src/lib/text/kstringhandler.h 1b08f6f > tier1/kcoreaddons/src/lib/text/kstringhandler.cpp 2f192aa > > Diff: http://git.reviewboard.kde.org/r/112717/diff/ > > > Testing > ------- > > Builds, affected tests pass. > > > Thanks, > > Aleix Pol Gonzalez > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
