As most of you will know by now, the KDE Development Platform team have been working on a plan for the next generation of our libraries under the working title of KDE Frameworks 5 (aka KF5 or KFV). This is the result of many different strands coming together, not least the decision by Qt to start work on Qt5 and the eagerly-awaited-but-not-quite-there-yet Open Governance model allowing us to directly contribute to Qt. This gives us a unique opportunity to look at how we structure our libraries and what those libraries provide, in particular their relationship to Qt5. My areas of involvement are Localization, Date/Time and Printing and I want to outline here the plans we've developed for them during discussions at Platform 11, the Qt Contributors Summit, and the Desktop Summit.
First though, I just want to re-iterate what we've been emphasising all along this process: this is not some radical change in direction, this is not KDE 5 or a switch to mobile platforms or some radical new user experience. The goal is that our application developers and users will not actually notice any change as a direct result of the KF5 work, it's simply taking our existing libraries and restructuring them so they are more modular and flexible to cope with whatever the future may bring.
First up Localization and Date/Time. Note that here Localization means things like number formats and measurement systems, not the Translation system. In KLocale we have very advanced and comprehensive localization options which includes advanced Date/Time features like Time Zones and Calendar Systems, and we allow our users to completely customise their Workspace locale settings. Unfortunately this support is a walled garden working in complete isolation from any other toolkit or platform: Gtk and Qt apps running under a Plasma Workspace don't use our localisation settings, and KDE Applications running under Gnome or Windows or OSX don't use the host Workspace localization settings.
To solve this I'll be working with the Qt Localization maintainer to implement full support for the Unicode CLDR localization standard in QLocale and QDateTime and to add a platform plug-in to load our Workspace settings into QLocale. KLocale and KDateTime will be moved to the kdelibs4support module and KF5 will use the Qt5 QLocale and QDateTime instead. This will solve the problem of Qt apps not using our settings and KDE apps not using the host settings, without losing any of our current features, but at the cost of some small source incompatible API changes. Yes, there is a Plan B in case things don't quite work out as planned. Loading our Workspace settings into Gtk apps requires a separate solution I have other plans for.
Printing is a much more complex situation. I've had patches to QPrinter improving the API waiting for a long time, but have failed to get them accepted into Qt, partly due to a lack of a maintainer at the Qt end and the high standards required. With Open Governance I'm hopeful we can get together a team of community maintainers to re-start bug-fixing and to push new features. I initially went to QtCS to volunteer to maintain the existing QPrinter code with my patches on top for Qt5. After discussions with the Trolls however we realised that the current QPrinter design has a number of limitations that we don't really want to perpetuate and support for the whole of Qt5. However neither myself nor the Trolls have the time to design and implement the new API before the Qt 5.0 feature freeze in October, which left us with a quandary.
The solution we've planned is to break out the existing QPrinter code into a separate QPrinterSupport module and namespace which will ship with Qt 5.0 but marked 'to-be-deprecated'. This will then give us time to refactor QPrinter hopefully in time to ship with Qt 5.1. That schedule works well for Qt, but not so well for KDE 4 where it would mean perhaps a further 2 years before our apps and users can actually start using the new module. To try fill the gap I'm thinking of forking the QPrinterSupport module as an 'experimental' Qt4 based QPrinterNG library. A first release could hopefully be made by the end of this year that would include all my patches and a number of other clean-ups and bug-fixes. KDE and Qt apps would then be able to choose to use this library instead of the current Qt4 QPrinter support while we wait for Applications based on Qt5/KF5 to emerge. I' could then use this fork as the base for developing the design of the new QPrinter module for Qt 5.1.
I'm sure a few of you are also wondering how the OpenPrinting Common Print Dialog fits into all this. The CPD solves a very specific problem, that is the broken state of print dialogs on Linux using Cups. It doesn't solve the problem we and Qt have of also supporting printing on Windows and OSX using the same API. We don't want our coders having to write separate #ifdef paths for Linux and Win/OSX support. The design of the new QPrinter API will be done with the CPD in mind and will probably use the CPD as the 'native' Linux print dialog if it is installed on a users system. If not available then Qt will still provide a fallback dialog of its own. I don't see Qt agreeing to ship the Qt version of the CPD itself inside Qt5, but it would be a Qt-Addon module hosted somewhere appropriate.
The good news about the CPD is that OpenPrinting has obtained some new funding to employ a full-time hacker starting in October to finish off the implementation of the dialog and to work with Ubuntu to integrate it into a future release. I hope to be working closely with the developer to ensure it meets the needs of Qt and KDE and smoothly integrates into our workspace and applications.
Hey, two blogs in two days, at this rate I'll have my blogging backlog cleared by the weekend :-)