Some notes from QtCS

John Layt jlayt at
Mon Jul 9 17:52:58 BST 2012


I just want to give some rough notes on a couple of the sessions I
attended at QtCS and my impressions on some of the discussions.  See
the Qt development mailing list for more detailed minutes from most

Minutes posted to list.
* ICU will become the Locale backend in 5.1 so will be a requirement
on all platforms
* Most platforms ship ICU anyway except for Windows, but ICU is
required for QtWebKit anyway so not a new problem
* Time Zone support comes built-in to ICU so will be used as basis of
new QTimeZone support in QDateTime, but will still integrate into the
* Time Zone api will be a lot simpler, but will be sufficient for
needs of KDEPIM

Minutes posted to list.
* In 5.0 QtPrintSupport is just a refactor, clean-up and bug fix release
* In 5.1 or 5.2 will be replaced with new module QtPrint that adds new
features KDE wants
* Can easily fix many problems and add features on Linux/Mac, but
Windows printing as always the problem
* Bug fix patches welcome!

No minutes posted as yet.
* Time based releases favoured after 5.0, perhaps every 6 months?
* More release team members needed, short on people
* Face many of the same issues as KDE, could learn from us

Presented by a guy from Nokia Commercial / Nokia Maps, none of the
actual devs were there so unable to obtain as much detail as I would
like.  No minutes posted.

* Not yet in feature freeze, was a near complete rewrite, not certain
if will make 5.0 release date
* Still one monolithic module for data containers, location services,
and mapping services/widgets
* Now depends on Qt3D to draw maps so dependencies heavier than before
* QML only in 5.0, C++ in 5.1 (I assume only means gui components?)
* Rendering said to be "ugly & slow", but improvements coming in 5.1
* Still tightly tied to Nokia Maps, other map plugins "possible" but
only Nokia implemented and likely to be supported by Nokia
* No layers any more?
* Big question over future, but Nokia Maps might be interested in
maintaining for potential revenue

Now, this is the impression given second-hand from a presenter who
openly expressed frustrations around the development and I haven't had
time to verify all he said.  I have confirmed there are Geoclue and
Gypsy backends for position services in master, but no mapping
services other than Nokia.  In short, there's a big question mark over
the continued existence or maintenance of QtLocation, and questions if
it's suitable for our needs.  Certainly it has failed to alleviate any
of the concerns I expressed about it at my Camp KDE talk.

I attended this with Volker who's probably better placed to comment,
but the general impression was the same as for QtLocation: a lot of
uncertainty over its continued maintenance, and being designed very
much around Nokia's limited requirements.  No minutes posted as yet.



More information about the kde-core-devel mailing list