[Development] ICU decision?

Saether Jan-Arve Jan-Arve.Saether at digia.com
Thu Aug 8 23:58:51 CEST 2013

...and LCMapStringEx can be used for generating sort keys.

However, there seems to be some things that need to be changed/removed from QCollator, such as the "index character" feature (I don't recall the exact function name). Also, the case sensitivity enum in QCollator can configure sorting to have (IIRC) upper first, lower first, or the default. IIRC CompareStringEx can only use the default or ignore case.

(However, I suspect upper/lower first might be possible to do with a qStableSort and QChar::isUpper())

There might be other small differences too, but at least it seems that the major feature can be done without ICU.

Jan Arve


Sendt fra min Nokia N9

07.08.13 21:42 skrev Knoll Lars:

On 8/7/13 9:29 PM, "Knoll Lars" <Lars.Knoll at digia.com<mailto:Lars.Knoll at digia.com>> wrote:

>On 8/7/13 5:21 PM, "Thiago Macieira" <Lars.Knoll at digia.com<mailto:Lars.Knoll at digia.com>> wrote:
>>On quarta-feira, 7 de agosto de 2013 08:00:27, Knoll Lars wrote:
>>> >The only "degraded experience" I would accept is "full functionality
>>> >C and
>>> >system locales". It would be acceptable for the classes to not have
>>> >support for other locales, like trying to get number formatting for
>>> >Azerbaijani on a German Windows.
>>> That would be acceptable for now IMO.
>>> The third option we discussed:
>>> * Require ICU, but have a 'fake' ICU lib available to deploy with Qt on
>>> Windows/Android for those who want to ship with minimal i18n support.
>>> some support to our packaging to choose which ICU lib to take.
>>Thanks for the suggestions.
>>If we go straight for option 3, can we get this fake library done in the
>>couple of months?
>It can be done, but the question would be who has the time.
>>If we go for option 2 first, we'd have to investigate if there is any
>>API to provide QCollator support for the system locale. Does anyone know
>>such a thing?

Looks like the CompareString/CompareStringEx methods should allow us to
implement collation on Windows without ICU.


>>I'm sorry, but I will block any task on making QCollator public until we
>>that we can have a working QtCore without an ICU dependency.
>But we can't (or rather should't) go for a least common denominator
>approach neither. A public QCollator won't mean a non working QtCore even
>if it has to fall back to unicode sort order on some OSes. And with ICU in
>place it'll all work fine.
>I agree that ICU is a large dependency, but we can't simply leave out
>important features forever because of this neither. and collation is
>something we have been lacking for far too long.
>Development mailing list
>Lars.Knoll at digia.com<mailto:Lars.Knoll at digia.com>

Development mailing list
Lars.Knoll at digia.com<mailto:Lars.Knoll at digia.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130808/1848cf3c/attachment.html>

More information about the Development mailing list