[Development] QtCS - ICU and Localization session
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.
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
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...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the Development