john.layt.net

Many of you will know Daniel Nicoletti, aka dantti, a KDE contributor to many projects such as the Print Manager, colord, Apper, PackageKit, etc.  You may also remember a couple of years ago that we dedicated a KDE release to the memory of Daniel's daughter who was killed in a tragic car accident in Argentina.

Daniel was flying yesterday from Brazil to the Czech Republic to attend the Linux Color Management Hackfest on behalf of KDE when he was detained at German immigration on an International Arrest Warrant related to the car accident.  He is now awaiting the German courts to decide whether to extradite him or release him, a process that could happen immediately or take up to 6 months to decide.

Obviously this is a very distressing time for Daniel and his family, and distressing for those of us involved in bringing him to Europe.  Daniels wife desperately needs to go to Munich to help coordinate his defence, and deliver to his lawyer and the German courts all the documentation they have  on the accident to allow the court to rule with full knowledge of what happened, but she cannot afford to do so.  If you would like to assist, she has set up a Pledgie where you can donate towards her flight.  Thank you.

The more observant of you out there may have noticed me popping up in the background of the recent KDE PIM Sprint, my first real KDE appearance in a while. Work has left me with very little time this year to do KDE and Qt stuff: we're not quite in a Death March, but it's getting close :-) However I made time to attend the PIM sprint to try and make progress on some of my pet projects.

I had plans to discuss a number of items at the sprint, including Plasma/Akonadi integration and ideas for new QML calendar widgets, but mainly I came to work on the new ICU localisation backend for Qt 5.1 which we plan to use in Frameworks 5 to replace KLocale, KCalendarSystem, KTimeZone and KDateTime. I've been working on the design for this on and off for quite a while now, but have only just got around to getting code written down and needed some time to just focus on getting it done. I've now pushed the first results to Gitorious for anyone interested in having a look (Warning: I ruthlessly rebase and push --force!). The code is still a little rough and broken in places but close enough to done to be worth looking at. Comments very welcome.

The core design was dictated by the somewhat opposing designs of QLocale and ICU. QLocale has the concept of Default and System locales which are shared objects in every application which consequently need to be immutable and thread-safe. ICU provides formatters that are created with a fixed locale and style, but all the other settings can be changed in a non-thread-safe way, and indeed must be changed to obtain anything other than the default formats, even simple things like changing the number of decimal places or padding requires mutation.

As a consequence I've defined two new classes, QNumberFormatter and QDateTimeFormatter, which wrap the ICU formatter object for a particular locale and style in an immutable Qt-ish API. Calling this API with options for non-default settings causes the formatter to be temporarily cloned and modified to return the desired results. Two more classes QCustomNumberFormatter and QCustomDateTimeFormatter extend the base classes with setters to allow permanent changes without cloning or messing with the default/system objects.

The QNumberFormatter and QCustomrNumberFormatter classes support the following styles:

• DecimalStyle // 10.00
• ScientificStyle // 1.0E2
• PercentageStyle // 10.00%
• OrdinalStyle // 10th
• SpelloutStyle // ten
• DurationStyle // 00:00:10
• CurrencyStyle // $10.00
• CurrencyCodeStyle // USD10.00
• CurrencyNameStyle // 10.00 US dollars
• DecimalPatternStyle // User defined pattern and symbols
• RuleBasedStyle // User defined rules

The QDateTimeFormatter and QCustomDateTimeFormatter classes support the following styles:

• FullStyle
• LongStyle
• MediumStyle
• ShortStyle
• FullRelativeStyle    // Today
• LongRelativeStyle
• MediumRelativeStyle
• ShortRelativeStyle
• IsoStyle    // 2012-01-01
• IsoWeekStyle    // 2012-W01-1
• IsoOrdinalStyle    // 2012-001
• Rfc2822Style
• Rfc3339Style

These new classes provide all the code required to replace the existing QLocale backend implementation as well as provide some new features like the Ordinal and Spell-out number formats, however that's not what really interests us in KDE or why I was at the PIM sprint. It's the next step of adding full Calendar System and Time Zone support into Qt that is the real pay-off. The ICU formatter already implicitly supports the default calendar system and time zone whatever it may be, but my current implementation does not as yet expose the ability to manipulate the calendar or time zone and that is the next step needed before integrating it all into QLocale and QDateTime. However, if you ask those sat next to me during the sprint who suffered my dark mutterings and hair-tearing, this is not going to be easy given the brain-dead design of ICU.

You see, ICU is notorious for being difficult to build against (don't ask packagers about the crazy library numbering and naming scheme), difficult to use and very poorly documented. It started life as a Java library, and it shows :-) The Java API was then ported to C++, but the C++ API comes with no binary compatibility guarantee as it's supposedly "too hard" to do. For an application that may be an inconvenience, but for a library like Qt it makes the C++ API basically unusable. Instead we have to use the C API which is a wrapper around the C++ API.

The problem is this C API is only a limited sub-set of the C++ API and while there is a partial API for Calendars with some Time Zone features, there is no C API provided for just working with Time Zones. You apparently can't even do something as simple as query what Time Zone a Calendar or Formatter is using. Then there is also the restriction we need to support older versions of OSX which ship ancient versions of ICU missing important features. It's going to take some ingenuity to work around these shortcomings, and naturally that is not going to be as efficient or reliable as I might like. Which got me wondering out loud about smarter ways of dealing with ICU, and this is where sitting in a room full of very clever people really comes in handy :-) After some discussions with Kevin and Sune I may have a proposal that allows me to use the full C++ API, but that's something for the Qt mailing list.

Interested in eternal fame and fortune within the KDE community? Want to be forever known as the person who implemented the Number 1 most requested feature in KDE? Read on and find out how!

In Luca's recent blog post he listed the top 10 KDE Brainstorm Ideas, and there at number 1 is supporting the creation of PIM events via the Plasma Clock/Calendar. This wish has also long battled it out for the Number 1 spot in bugs.kde.org voting as well. And it's something I promised to do at the last Akademy nearly two years ago. Whoops :-(

Implementing 2-way PIM support requires two separate pieces of work. The obvious part is making changes to the Clock/Calendar Applets to create Events, but before that can happen we need to create the back-end Plasma Service that will talk to Akonadi to do the actual work. It's writing this back-end code that I've stalled on due to too many other commitments, and it's where you can find eternal fame by picking it up.

I've documented almost everything I know about the current state-of-play of the Plasma Clock on the Community wiki, so anyone interested can pick-up where I've left off. The page points to various resources and provides a basic outline of what needs to be done to create the Plasma Service. I've also put down a few ideas about improvements to the Applets which people are free to ignore.

A key point here, and a lesson hard learned when we wrote the read-only PIM DataEngine is that PIM is a complex subject area and Akonadi is our abstraction layer designed to make PIM easier. Trying to fully re-implement all the Akonadi API and specialist GUI widgets in Plasma is not a very smart idea. Plasma only needs to offer a basic level of services that general use Plasmoids like the Clock need to offer, such as adding a single-occurrence Event or a Todo item. Any advanced features like recurring Events and meeting invitations should be left to the PIM applications via an option in the Plasmoid to launch the full application. If someone wants to write a Plasmoid to support complex PIM editing then they should directly use the Akonadi API in C++, or generate proper language bindings for Akonadi / kdepimlibs in their language of choice.

Another feature we need added in Plasma is the ability to choose what Events to display. At the moment we are just pulling in the Default Calendar (or is it all Calendars?). What would be great is if you could choose which Akonadi Collections to display, i.e. only show Personal Events in your Personal Activity, only show Work Events in your Work Activity. Again, this requires changes in both the DataEngine and the Applets.

One other area that needs solving is what to do when a user doesn't actually use KDEPIM or Akonadi for their PIM needs but Akonadi has still been installed by the distro by default? At the moment we launch Akonadi by default inside the Plasma Calendar as soon as the user clicks on the Clock, and query it for any available events. Naturally it finds none, but by then it is too late, Akonadi has been launched and is seen to be using resources. "Oh noes, big bad bloated KDE!" Many distro's avoid this by changing the default setting to not showing Events, but then users may not realise that they can be enabled. A far better solution would be if there was a passive way to query if any Akonadi Calendar Resources have been configured and only launch Akonadi if they have. We could also then offer a wizard to configure Akonadi Resources if none have been. This of course is something that would have to be implemented by the KDEPIM/Akonadi team.

I had originally planned to post this before Akademy and say "come speak to me at Akademy if you're interested" but sadly problems at work led to my leave being cancelled and my having to miss Akademy for the first time in 5 years :-( So instead if you're interested in working on any part of this, please drop a line to the Plasma or KDEPIM mailing lists as appropriate and I'll get back to you.

Enjoy Tallinn!

With the necessary work on Localization for Qt 5.0 winding down In the last couple of weeks, I’ve been able to concentrate more on my role as maintainer for the Qt Printing module. As maintainer I get to co-ordinate all activity on Printing, manage the bugs, approve and merge changes, make sure the module is in a fit state for release, and have a major influence on the future direction for Printing. That may sound very grand, but what it means in real practical terms is the doors are wide open for bug fixes in both Qt 5 and Qt 4.8.

With my primary focus right on preparing QtPrintSupport for the release of 5.0, I don't yet have the time to fix existing bugs from 4.8. This is where you could help. If you can code and are interested in helping out, I’m happy to allocate existing bugs to people to fix and approve the resulting patches. If you don’t (yet) code and have a favourite bug that you want killed, check to see if it is in the bug tracker and if not report it. Help triaging the bug list to see what is still valid in 4.8 would be also be welcome.  Just remember all bug fixes must first be applied to Qt 5 then backported to Qt 4.8, and no new features are allowed.

I’ve done a quick bug triage and there are currently 137 open bugs. I’ve organised these into groups of related bugs and opened Tasks to track them:

• QTBUG-25381 QPrinter - Qt 5.0 Release Task
• QTBUG-25372 QPrinter - CUPS Settings In Linux Print Dialog
• QTBUG-25384 QPrinter - Windows related issues
• QTBUG-25383 QPrinter - Mac OS X related issues
• QTBUG-25380 QPrinter - Page Size and Margin Related Issues
• QTBUG-25379 QPrinter - PDF Generator Related Issues
• QTBUG-25378 QPrinter - Font Related Issues
• QTBUG-25377 QPrinter - Remote Printer Issues
• QTBUG-25385 QPrinter - New Printing Module requested features

If you’re interested in helping get printing into shape then these Tasks are a good place to start. For Linux / CUPS users the good news is a Digia developer has stepped up to sort out most of the long running issues around CUPS settings in the print dialog, and he also plans to make improvements to the PDF generator in 5.1.

An area that is particularly problematic is testing printing, especially in the Continuous Integration system where we don't actually have physical printers attached to the test machines, and we can't rely on networked printers being available.  One option I'm trying is writing a virtual CUPS backend to work under Linux and OSX, but that involves a manual setup process and messes up the  printer config for any real testers.  If anyone knows of other testing straegies under such circumstances I'm all ears.  I undertake quite a bit of manual testing as well, and to help that out I've recenly purchased a new networked duplex laser printer to enable me to test those features.  Just as aseigo recently experienced, installation was a very easy plug-n-play process under Linux and OSX, but reboot hell under Windows :-)

One problem with working on Qt itself is the lack of internal project documentation. To help improve that I’ve started a Qt Printing hub page on the Qt wiki to try document how QtPrintSupport currently works and to plan out the future direction. It’s rather empty at the moment, but hopefully it will grow over time into a comprehensive resource to enable more people to contribute.

You may remember the plan hatched for print support in Qt5 back at the Qt Contributors summit last year. The current printing module is not really up to scratch and needs replacing, but we didn’t have the time before 5.0 to rewrite it. Instead for 5.0 we’ve broken the old code out into a separate library inside qtbase called QtPrintSupport. This module is marked in the Qt Maturity model as ‘Done’, meaning it will be supported and maintained for the life of Qt5, but no new features will be added. The plan is then in Qt 5.1 or Qt 5.2 to introduce a new QtPrint module.  I’ve made a very high-level start on the design of the new QtPrint. The plan is to design an IPP style API that can have pluggable backends for different print systems like CUPS, OSX, Google Cloud Print, Hp ePrint.  I'll be progressively working on the design in the next few months with the aim of running a session at the Qt Contributors Summit to finalise the details.  If you have any ideas or wish to help then I'm all ears.  Implementation though will come after I complete the new ICU localisation backend.

And if you got this far, here's something to reward your efforts, a Bronze Age Barbed and Tanged Arrowhead that turned up in a Bronze Age barrow I was excavating last weekend.

Wow, some 7 months since my last blog post, I have been bad :-)  Obviously life has been rather busy this last 9 months since going back to full-time work, strangely my employer expects a full 8 hour day, then there's the 4 hour commute, plus university studies in the evening and various excavations on the weekends.  Needless to say my time for KDE has been severely limited and what little time I have has mostly gone into working on Qt 5 trying to improve the Localization and Printing modules.

Before I get into some dry details, I'll give you a couple of pictures in compensation.  First up aseigo may recognise these two characters who I've had the good fortune to work with a couple of times now:

If you watched the Time Team special on Isambard Kingdom Brunel then you might have spotted me wandering around in the background trying to get into camera shot :-)  However archaeology is about more important things than TV stardom, it's about digging up cool stuff right?  Well here's my best find to date:

I would show you where I found it, but I think 1600 year-old Roman skeletons don't quite belong on the Planet :-)

Anyway, enough of that, how's Qt 5 going? I'll cover printing in a separate post, so here I'll cover Localization.  The plan was to overhaul QLocale for Qt 5.0 to fully support all KDE's requirements, including proper calendar and time zone support.  After a couple of months working on that and discussions on the Qt development list we realised that the amount of extra code required and the memory consumption of the extra locale data was going to be excessive if we stuck to the current implementation model, and would work against the plan for a slimmed down QtCore. 

After a bit of thought it was decided that instead Qt5 would switch to using ICU as the localization backend.  ICU ships on all modern Linux distributions where it is used by apps like Mozilla and LibreOffice, is used by OSX, iOS and Android, is available on Windows and is already a pre-requisite for QtWebKit so for most cases the dependency will not be an issue.  Obviously the native host locale functions will still be used for the system locale, but ICU will provide the Linux system locale, and non-system locales on all platforms. This will greatly reduce the amount of code we have to write and maintain, and will give us a lot of new features like collation that we don't even have in KDE.  It also means locale data is no longer all stored in libqtcore so distros and embedded users can slim the data files down to just what they need.  About the only down-side is I no longer have calendar code to maintain :-(

Unfortunately this meant starting over, and with not enough time to fully implement support before the feature freeze I concentrated on making what source and binary incompatible changes were needed to be made for 5.0, while still maintaining near-100% API backwards compatibility.  Now that stuff is really boring, but if you ever wanted to instantiate a QDate that lay anywhere in the range from Big Bang to heat-death you now can :-)  Probably the most important part of this work was getting used to the Qt code-base and the Open Governance model, which I think is bedding in quite well now.  The new QLocale API wrapping ICU will be introduced in Qt 5.1 in time for KDE Frameworks 5 to use it for its initial release, as well as the KDE Platform integration so that all Qt apps use the KDE locale settings.

Hey, now university is over for the year, perhaps it's time to venture back onto that great time-sink called IRC :-)

Dear Lazyweb :-)

Barely having enough time to draw breath at the moment, I thought I'd abuse the Planet again for some help.  My brother Paul is the volunteer technical manager of his local community radio station in Christchurch, New Zealand.  Radio Ferrymead specialises in playing golden-oldies from the original vinyl 33's, 45's and even 78's using the original equipment, and also houses the local Museum of Sound and Radio. Paul is the hardware guy in the family, so most of his time is spent rigging aerials, maintaining the transmitter, replacing turntable needles, fixing the vintage mixing desks and trying to coax antique radio gear back to life, but he also has to look after the station's music library software and there lies the problem. 

The station has a library of over 55,000 records and 368,000 tracks organised using a rather quirky classification system and Windows 95 era software.  New records are catalogued in the system, then the DJ's query the software to find the location of the records they want to play and laboriously write the details out by hand.  The software was custom written and maintained by one of the volunteers at the society who left a while back in a huff and refuses to release the source code, documentation or even the binary file format used for the database, leaving them with near useless software that could fail at any time and unable to liberate their own data.  Such are the perils of closed source software. 

Enter the software guy in the family :-)  Thanks to the O-for-Awsome Okteta, I've slowly been able to reverse engineer most of the binary file format and extract the main track and album details, although some of the details still escape me.  The things people used to do to save storage space.  Ugh.  Anyway, now we are this far we need to come up with some replacement software that replicates the quirky cataloging system as closely as possible: unsurprisingly they don't want to have to re-catalogue the entire collection.  Ideally I would just write a custom Qt or Kexi/Access type app to do so, but I really don't have the time so I'm looking for some open source software that will fill their needs for now but also provide options to help them better manage the station in the future.

The main features required are:

• Copes with high volume of data
• Import existing database
• Customisable fields for classification and library location
• Supports physical media attributes, e.g. type, side A/B, speed, size, material, condition, etc
• Link multiple physical copies of same record
• Also supports Cassettes, Cartridges, CD's and MP3's
• User management or read-only mode so only library staff can add/modify entries
• Some reports
• Exports database in some standard format
• Fast and flexible search on all attributes
• Runs on Windows (unfortunately for now)
• Simple and reliable
• Standalone, doesn't need internet access or a server
• Easy to use for vintage users

Future features I'd like to see:

• Manage shows: build a show's playlist, print out the playlist with library locations and runtimes etc, save the playlist so DJ's know what they've already played and when, export to website, etc.
• Discogs.com integration
• MP3 library management and playlist generation for automated overnight shows
• Manage schedules
• Manage listeners requests (old skool over the phone or via mail)
• Manage community announcement requests
• etc...

So while a fairly basic music database might suffice for now, it needs to have room to grow.  I'm not looking for full station automation software or an all-digital station, that's too complex and not what they are about.  Most of the stuff I've looked at so far is designed for CD or MP3 collections and is just not flexible or robust enough.  Tellico looks like an option and has Discogs integration already, but is it available on Windows?  So lazyweb, any other suggestions?

I've had a little time to play with my ExoPC tablet kindly provided by Intel, and after a brief look at the MeeGo/Intel tablet UX decided that Plasma Active was the way to go (sorry Intel!). The MeeGo UX is far from complete and the lack of applications made the tablet next to useless for anything besides basic web-surfing. Plasma Active, on the other hand, is a full openSuse and KDE install and so has many apps to play with. Plasma Active itself is remarkably usable already and has some nice features that actually work the way I expect a tablet to function. It's amazing how far the Active team has come in such a short time and that's a tribute to both the Plasma architecture that Aaron put in place and the flexibility of our Platform/Frameworks. If only Intel had approaced KDE first...

The compelling story here is that all our apps run straight out-of-the-box (albeit not all touch friendly yet), a ready made app 'eco-system' that we don't need to bribe developers to foster. It's amazing how usable many of our KDE apps are by default, many apps will take only a few modifications to be fully usable and I look forward to the necessary standards/guidelines to come out of the Active project so we get a consistent experience. If we just had some way to trigger a right mouse click even more apps would become usable (e.g. KMines), could we map a long-click for this?

We've just had a long holiday weekend here in the UK and I spent the time in a French farmhouse somewhere in Normandy with some friends and their four children aged between 5 and 12. We may have been berift of net access, but the tablet was fully loaded with edu apps and games and was given a through going-over, err I mean usability test by all the children. It took a single demo from me of how to find and launch apps and they were away, proving just how usable Active is: if a 5 year-old can get it with a 3 second explanation I'm sure most adults will too. A tablet works really well in the context of a group of children playing together, they happily sat around the tablet playing Blinken or KHangman together, rather than arguing over who's next to play Angry Birds on the iPhone. The 5 year-old even demanded his parents install some of the games on their iPad :-) As annma put it on the kdeedu mailing list, a tablet is a ready-made babysitter :-)

Many of our edu apps and games just work and need no real changes, others are a little awkward needing right-clicks or with the virtual keyboard covering entry boxes, but I know both teams are looking at ways to redesign their gui's to work better on all formats. For edu apps aimed at the 3-10 years age-group I think the touch style interfaces with all the required tools visible in the main window is actually a good fit for all the formats. If you want to try your hand at designing new QML based ui's for existing apps then drop in on the kdeedu list, I'm sure they would welcome the help.

Also a big hit for all ages were TuxPaint and Micropolis, two apps we currently don't have equivalents for. TuxPaint should come as no surprise, but for a 20 year old piece of software Micropolis worked amazingly well, probably aided by pre-dating the coming of RMB context menus. If anyone is looking for a more substantial project to work on then these would be good candidates. TuxPaint is a lot of fun but doesn't play well on non-standard screen resolutions and the gui is non-standard, perhaps someone wants to do a Kids mode for KolorPaint? Micropolis apparently has all the backend logic separated out into a C++ module and can use Cairo as a canvas, but seriously needs a modern gui.  Surely it can't be too hard for someone to switch it to a Qt-based canvas and gui?

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 :-)

My Desktop Summit was a very busy one, I gave a talk, chaired three BoFs, was on a RadioTux discussion panel, wore a red-shirt but didn't die, attended the eV AGM, participated in many other BoFs, and worked the hallway tracks discussing everything from KF5 / Qt5 to the upcoming Rugby World Cup. I wasn't helped by catching the dreaded conference flu and with all that talking my voice was suffering, but I take it as a good sign that I didn't write a single line of code until the Thursday when things finally started to wind down. Oh, and apparently there were parties. And it rained.

Among the highlights for me were:

• The Simon speech recognition talk and demonstration showing just how powerful and easy voice control can be. I want it, and I want everyone else to have it too :-) If you're an app developer you really need to upload a scenario to enable support.
• The Toaster Project keynote, a very funny but thought-provoking talk that mixed the Open Source ethos with conceptual art and experimental Archaeology. Well worth watching when the videos come online.
• A very well deserved Akademy Award to Toma and the Sysadmin team, who as well as keeping the existing infrastructure humming along so smoothly also found time this last year to build a world class Git host.

The best part was that this Desktop Summit didn't feel like two separate conferences under a single roof, but a genuine attempt at collaboration with two communities starting to mix together and explore what common ground they have. This was especially true of the BoF sessions where we had cross-desktop groups sitting down and talking to each other to work out practical collaborations, sometimes for the very first time. I was personally involved in such sessions on Colour Management and Printing, but I also saw groups on Hardware, Bindings, Multimedia, Accessibility and several other topics getting to know each other. Given the issues in the last few years around infrastructure projects being delivered without KDE integration it's great to have the people involved building the relationships required to ensure these things go smoother in the future.

I came to the DS with some reservations about whether it was something worth doing again, and while there were still a few incidents that gave me pause for thought, overall I'm now a lot happier for a third DS to take place, hopefully with a greater involvement from some of the other desktops and platforms (XFCE, LXDE, MeeGo, etc). We're learning as we go, but it's on an upward curve and well worth the effort. My only real disappointment was that freedesktop.org wasn't discussed, it's the one time we have all the key players on hand but it became the elephant in the room. I'd really like to see some fresh thinking around what fd.o should do besides being a hosting site / dumping ground for any project trying to claim cross-desktop credibility.

I was also one of the lucky number who attended the Intel AppUp session where, as well as learning about the possibility of using AppUp as a KDE distribution channel on MeeGo (and maybe Windows?), I also got a 'new' ExoPC tablet on loan to play with. You may be wondering what a libs hacker like me needs a tablet dev platform for? Weeellll… If all the plans for KF5 and Qt5 come off, then I will have largely done myself out of a localization job and I'll be looking for something new to hack on. I have some ideas for a touch-friendly calendar-widget, there's Marble stuff I'd like to get into, my long-planned genealogy program (the reason I started all this date and calendar and localization stuff in the first place) would be great to browse in tablet/touch form especially when doing archival research, and then there's the possibilities of using tablets in the field for archaeology that could be a good MA research subject if I decide to go back to school next year. Oh, and a touch-friendly print dialog would be good too. Hmmm, that's a lot to be getting on with, guess I better hurray up with that Qt5 stuff eh?

I'll try blog a bit more soon about my talk, the RadioTux panel, my plans for localization and printing in KF5 / Qt5, what changes I made in KDE Platform Release 4.7, perhaps some more thoughts on fd.o, and just where the heck I've been these last couple of months (hint: some of it involves a couple of blokes called Tony and Phil and a lot of mud).

[Edit: Updated the sponsors list]

I'm home from the Platform 11 Sprint in Randa, Switzerland, where I had a fantastic 7 days with the KDE Core team discussing the future of KDE's Development Platform. The temperature outside may have been 0 degrees and snow on the first morning, but inside it was an intellectual hothouse as some incredibly smart people (and me) debated, designed and hacked all hours of the day and night. The summary emails are now slowly making their way onto the mailing lists for wider community discussion and a dot article will follow to communicate the big picture to the wider world, but what I want to share here are my personal thoughts on the conclusions we reached on where the Platform that our Applications and Workspace are built on is heading in the next few years.

Firstly though I want to thank Mario Fux and all his volunteer crew (especially his parents) for their fantastic effort in hosting 60 hungry hackers in such a beautiful corner of the world (those mountains sure are distracting when you're supposed to be staring at a screen) and look forward to the opportunity to visit for another sprint. Thanks also to the sponsors, especially Bar Informatik AG for the internet access, Swisscom for the Swiss Army Knives, and openSuse for their help with everyone's travel costs and t-shirts.

In the KDE community we produce many fantastic Applications and a great Workspace which have lead to the production of some equally fantastic common libraries and frameworks to share common functionality. The problem is after 15 years of striving to produce a Kool Desktop Environment most of our libraries are rather unsurprisingly structured to support a monolithic desktop environment. The reality is we now live in an incredibly diverse and even more rapidly changing tech world where no one platform or form-factor will dominate like the old wintel desktop days when KDE was coming of age. While that may mean KDE will never achieve World Domination via the desktop, it also means there has never been a better opportunity than now for KDE to establish a significant presence in these new markets. I want to use all those great KDE Applications on every Kool device I own, even those where I can't run a KDE Workspace (and even better on those where I can). To do this we need to adapt our libraries to meet the challenge of surviving in such a diverse world so we can equally support these exciting new form-factors as well as our classic and much loved desktop.

In recent years we have slowly been moving the Development Platform towards such a modular approach, the 4.0 release made some major strides towards this, and now with a modularised Qt5 being announced under Open Governance we have the opportunity to complete the task. By evolving our Development Platform to a more modular and flexible set of Frameworks that integrate better with Qt we can continue to provide the same stable high quality foundations our existing Applications and Workspaces rely on while providing a flexible and light-weight foundation for exciting new developments to innovate on.

We're very mindful however of the pain a disruptive transformation can cause and that's something we don't want to do, which is why one major overriding goal for Platform 11 was how to achieve what we need to with the Frameworks while having the minimal impact on our existing Applications, Workspaces, and Users. I think the plan we developed manages to do this, and if we succeed then most people will not even notice something significant happened beneath their feet.

One benefit we're hoping from all this is opening up KDE developed libraries to be used by the wider Qt developer community, making KDE the go-to place for libraries and frameworks extending Qt. More users of our frameworks means more eyes-on-code and possibly more contributors to that code, and can be a gateway for more involvement in the KDE community. I really believe Open Governance is an exciting opportunity for KDE to improve and grow and one which we need to work hard at to make succeed to guarantee our future survival.

For the KDE Core team, finishing Platform 11 is only halfway through an incredibly busy couple of weeks work with the Qt Contributors Summit coming up next week where we will be discussing with the wider Qt community how to get involved in Qt Open Governance. The KDE agenda will be a mixture of helping establish the new community and figuring out how it will operate, and working out the technical aspects of where KDE can contribute code and features to Qt5 . Platform 11 gave us many great ideas on how we can better work with Qt and simplify our Frameworks by making some key contributions to Qt and we will be working hard to make it happen. For me it will also be the chance to pursue the topic of Printing, which didn't feature at Platform 11, to finally get my patches into Qt and to work to improve Qt to the level of our much missed KDEPrint.

Now, I really need to go and catch up on my sleep :-)