[Development] ICU decision?

John Layt jlayt at kde.org
Thu Aug 8 22:12:57 CEST 2013

On Wednesday 07 Aug 2013 16:23:49 Thiago Macieira wrote:

> Can you list the above in the form of Qt API? I'm not sure we have most of
> what you listed above in our API today and we don't have any plans of adding
> them...

Sure :-)  These are still WIP but were originally modelled on ICU and are now 
being revised based on what's available in Mac.  General design is one 
formatter object per "style", as that's how ICU and Mac do it, i.e. we wrap 
and manage one of their formatter objects.  The base class is designed to be 
thread safe and shared so no setter methods.  A derived 'custom' class does 
have setters for convenience so is not thread-safe.

QNumberFormatter - implemented for ICU and Mac (95%), need to see how much 
Win32 supports:

QDateTimeFormatter - implemented for ICU so far, pretty sure Mac and Win32 
will have full or near-full support:

> I understand that there is a lot of features that KDE wants, and under other
> circumstances I wouldn't hesitate to give, but at this point I need to
> weigh the cost: if giving this API will require a major dependency we're
> not prepared to give.

The main aim for KDE in 5.2 is for api parity for what is currently needed in 
kdelibs/KF5, so time zones and calendar systems.  However I'd also like to 
have ICU date/time format code support rather than the existing quirky Qt 
format codes as we have to switch from POSIX format codes and I'd rather do it 
once properly.

As I've said before, I think I can get all the current QLocale functionality 
plus time zones and calendars done using native api on Win32 and Mac, and hard 
require ICU on Linux and QNX to get calendars.  I'm not as concerned at 
getting the new formatter api in for 5.2, but the code is there to use for the 
Linux/QNX ICU backend, and to improve the system locale code.



More information about the Development mailing list