Hi, With Qt 5.0 now effectively API and feature frozen, I thought I'd update everyone on my progress (or lack there-of) with pushing stuff from KDE into QLocale and QDateTime.
The bad news is that none of the new date API made it into 5.0 and has now been put off to 5.1. This is mostly down to Qt deciding to go with libicu as a localization backend, meaning all the backend code I had written got trashed and I didn't have time to re-wire the api to ICU. The better news is I did get a number of BIC and behavioural changes in to tidy things up and extend the supported date range. The new API is also fairly well nailed down, except for the new QTimeZone which needs work. Qt 4.8 has already added a lot of the other api we needed. Once the new ICU based code is in Qt 5.1 we get pretty much the full set of locale features in a standard cross-platform way, even if api to control it is lacking at first. The implication of this is that any switch to fully using QLocale and QDateTime will have to depend on Qt 5.1 and we have to decide if this is acceptable. Most things in kdelibs/frameworks could be switched right now with minimal visible difference, except for Calendar (and thus all the date widgets) and Binary. The impact on apps using frameworks would be far greater. So, do we accept the risk and start porting, or do we keep using KLocale until it feels safe? I'm pretty confident we will be OK. I think the Tier 1 libraries should definitely switch now to using QLocale and tr() exclusively. I see no point in delaying their switch as we want them independent of KLocale entirely. Their use of KLocale should be minimal anyway. Any other framework code using straightforward locale methods can probably be switched straight away too. It's only code using Binary and Calendar methods that will need to continue using KLocale for now. I've now created a page at [1] detailing the possible migration path. It sketches out how to replace KGlobal::locale() and starts mapping out the KLocale to QLocale api conversion. I'd appreciate any comments people have. [1] http://community.kde.org/KDE_Core/KLocale/Frameworks Cheers! John. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel