On 19 July 2013 14:15, Aleix Pol <aleix...@kde.org> wrote: > On Fri, Jul 19, 2013 at 1:17 PM, Aleix Pol <aleix...@kde.org> wrote: >> >> Hi, >> I was looking at that task in the Qt5 epics list and I didn't understand >> it fully. >> >> contribute natural-comparison to Qt5 (see KStringHandler). In Qt there is >> naturalCompare function but private and not as good as from KStringHandler. >> Thiago says: add the feature to QCollator. >> >> Here's the problems I see: >> - I don't know what's the goal of the task, so it's hard for me to decide >> what to do. >> - The one Qt5 has now, it's in QFileSystemModel >> - QCollator is also a private class, do we need to have it available from >> the public API? I guess the only use of it is in any tier1 module. If so, >> why QCollator? >> - In the code we have in KStringHandler we can find this comment: >> // This is based on the natural sort order code code by Martin Pool >> // http://sourcefrog.net/projects/natsort/ >> // Martin Pool agreed to license this under LGPL or GPL. >> >> I don't feel very comfortable with moving this code over to the Qt >> project. >> >> Aleix > > > Hi, > So after talking a bit with wojtask9. > > Apparently the thing is that our itemviews module needs > KStringHandler::naturalCompare, and we want it to be tier1 (thus can't > depend on KCoreAddons). > > Additionally, he showed me this review [1] that suggests moving QCollator to > public API. This solves the 3rd point. I guess that then we can add a public > naturalCompare function in QCollator for easy natural comparison. > > For the moment, I'll update the explanation and release the task since > there's little we can do with a private QCollator. > > Aleix > > [1] https://codereview.qt-project.org/#change,50372
It's not an area I know much about, but QCollator is still private and as far as I can see currently needs ICU to actually work. I guess that goes on my TODO list then as part of the ICU work. If we can find a Windows Win32 api that does the same thing or close enough we should be able to move it forward more quickly. Otherwise we will need our own fallback implementation. John. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
