[Development] QtCS - ICU and Localization session

Thiago Macieira thiago.macieira at intel.com
Fri Jul 26 21:23:43 CEST 2013

On sexta-feira, 26 de julho de 2013 19:33:40, John Layt wrote:
> I've started work on refactoring QLocale and my existing ICU api code
> to try make this work and should have a working proof-of-concept in a
> couple of weeks.  At the very least, even without making the new
> classes public this should result in a cleaner QLocale, an ICU backend
> for use on Linux and QNX, improved Mac and Win32 support and smaller
> library size on most platforms.
> Thoughts?

Thanks for the braindump and analysis, John. It's appreciated.

I find myself agreeing with almost everything you said. The one thing I 
disagree with is maintaining our old database in Qt. Past experience teaches 
us that anything but the default build will bitrot and will be hard to 
maintain. It hasn't been one year that we started using ICU instead of iconv 
and the iconv code already has shown build issues every now and then -- and no 
one knows whether iconv on Windows is supposed to work.

So I would request that we seriously consider deprecating and later dropping 
completely our own database. I would put the implementation on two levels:
 1) baseline and mandatory: system/user config
	backends: POSIX, Win32, OS X, BB services, whatever Android uses
	(the first four are already present, the POSIX one needs work)
 2) database support (optional)
	backends: ICU, OS X's ICU wrapper, Win32, ICU4J via JNI

The first level is the implementation that gives the application access to the 
user's current locale settings. For the overwhelming majority of applications, 
that's actually quite acceptable: users don't often run applications in 
different languages than their OS, or parts of the application.

In turn, it takes the burden off the backends for the second level. If the 
ICU4J backend (for example) is missing or slow, it won't be a big deal.

That would leave us with the task of implementing a very good "system/user 
config" module. That would also mean bringing the iconv converter back to 
working condition.

The one problem I see is QCollator. I don't see the baseline implementation 
providing enough data for us to implement said class. I'll be happy to be 
proven wrong, though. But if I'm right, my suggestion is to remove this class 
from QtCore -- it's still private and not used anywhere. We can provide it 
elsewhere and make the ICU dependency explicit there.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130726/533a8ee9/attachment.sig>

More information about the Development mailing list