[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