[Development] ICU decision?

John Layt jlayt at kde.org
Wed Aug 7 00:22:59 CEST 2013


On Tuesday 06 Aug 2013 09:22:57 Thiago Macieira wrote:
> Have we reached a decision?
> 
> I'd like an answer: do we depend on ICU on all platforms? Or will we allow
> platforms to build without ICU?
> 
> I'm talking about QtCore here. WebKit is a whole other matter.

Sorry, have a half completed reply to your previous mail I must finish...

Anyway, far as I can see, we cannot depend on ICU on all platforms, because we 
can't rely on a usuable system library to be installed on most platforms, and 
building and shipping our own is just opposed by too many people, mostly on 
size and complexity issues.  At least for 5.2 anyway.

For localization, we can depend on it on Linux and QNX and it should be our 
native backend there.  On OSX/iOS we use their native api instead.  Same for 
WinRT when it happens.  Win32 we can support QLocale and new QTimeZone and 
QCalendarSystem classes using native api, but not advanced number or date 
formatting.  Android needs more input as to whether JNI would be performant 
enough.

It's more code to maintain, but the only workable way I can see, and less code 
than we currently have.

The  question really then is how to expose the advanced features from an 
optional ICU:
* Separate module
* In QtCore, but classes only available on Win32 if ICU used
* In QtCore, but with a Win32 backend that has a degraded experience if ICU 
not used

I'll put more background in my reply to your other mail.  My QNumberFormatter 
class now works with both ICU and OSX/iOS, and I'm about to try do a Win32 
backend to see exactly what's missing, so I should have hard data for you by 
the weekend.

Cheers!

John.




More information about the Development mailing list