john.layt.net

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

Just a reminder to people we have some Git documentation on TechBase detailing some recommended Git configuration options and some common Git Recipes to follow when doing common Git tasks. There's a lot still to be documented, feel free to contribute.

One such recipe I just want to emphasise is Cherry-Picking, especially if you are using a cherry-pick to forward or back port changes between stable and unstable branches. Please use the -x option which will automatically include the sha of the original commit in the new commit message which makes it easy to monitor what patches have been ported. You can also use the -e option to edit the commit message if you need to change the BUG: or FIXED-IN: tags.

The Google Summer of Code student submission deadline is looming in a couple of days and I want to make a little noise around some ideas that I'd like to see students applying for.

First up are some GSoC projects not actually mentored by KDE but that we will be helping coordinate. The Linux Foundation OpenPrinting Workgroup has spent several years working on some concepts for improving the Linux Printing systems and the whole printing user experience. This year they are hoping to complete the push to making the Common Print Dialog and Colour Management available in both KDE and Gnome and have a number of GSoC slots available to do so. Even if you're not interested in printing itself these are great projects to work on to learn about joining up lower levels of the Linux infrastructure with the major gui toolkits and desktops, and on how to build a major dialog in conjunction with some top usability experts. You'll also get the satisfaction of knowing you have helped solve a major problem for Linux and KDE and the knowledge that every time a Linux user prints something they are seeing your work.

Within KDE there's two related projects I have posted on the ideas list which I am willing to mentor. The first is support for Astronomical Calendar Systems in kdelibs such as the Islamic, Chinese and Hindu calendars. The other is adding support for Alternative Calendar Systems into Kontact, such as calculating recurring events using non-Gregorian calendar systems and displaying dual calendar systems in the one calendar view. I have heard from potential students for these projects, but choice is good and extra input and ideas always welcome.

Finally, there's a couple of projects that I'd like to see students working on. The first is in KStars working on separating the astronomical calculation code from the ui code, which is related to both the Astronomical Calendar Systems project and KHolidays and may result in some code sharing. The other is implementing a new vector layer in Marble using the Natural Earth dataset, which would not only give Marble up-to-date country borders but also make libmarble usable for many more use cases such as education or data visualisations (e.g. KGeography).

Greetings from San Francisco where I'm currently attending Camp KDE, that geek-fest that is the annual North American KDE community meet-up. We're well into the second and final day of the conference and it's been a great time so far. There's been some great talks, a fascinating evening at the NoiseBridge hack space, and no end of talking to fellow KDE people about World Domination and how to achieve it.

Of course, it's been a lot more fun for me since I finished delivering my talk on Geolocation Services in KDE yesterday afternoon :-) In traditional fashion I didn't finish writing my notes until an hour before my talk was due, and the usual hardware issues with Mac hardware, Linux NVidia drivers and projectors meant the live demo section had to be abandoned, but overall it went well and the feedback afterward was positive. Best of all, during the talk I mentioned an issue that prevents KDE using GeoClue, and within minutes we had an impromptu group on irc working up a patch to solve the problem which Gary Greene will be sending GeoClue's way in the coming weeks. The talk slides and video should be uploaded in the next day or two if you're interested.

Tomorrow the Linux Collaboration Summit starts and on Thursday I'll be participating in the OpenPrinting Summit sessions to discuss the Common Print Dialog, so I still have a busy week ahead of me before I can relax and enjoy some sight-seeing around San Francisco.