Randa is a special event in the KDE calendar.
Randa is special as it is a tiny village high in the Swiss Alps with few distractions beyond the stunning scenery. Participants have little else to do than talk, think, hack and sleep.
Randa is special because it lasts an entire week, giving participants the extended time needed for deep thinking and planning for the future of KDE with few outside distractions.
Randa is special as it has been the genesis of many great KDE initiatives, including the conception and planning for KDE Frameworks 5 some 3 years ago.
Most of all though, Randa is special because it is a community event, conceived and organised by a member of the KDE community as his contribution to KDE, funded directly by the community members, and delivering tangible results back to the community.
If you appreciate KDE, then you need to appreciate Randa and support its fundraising effort today.
Significant changes have been made to the internals of QtPrintSupport in Qt 5.3 in an effort to resolve many of the page layout bugs and inconsistent behaviour across platforms, as well as preparing the way for printing on mobile devices and cloud printing in Qt 5.4 or 5.5. These changes were not in Alpha 1, but have now been merged for the Beta 1 release and need through testing to ensure they work properly with the wide variety of print devices and drivers out there.
The main changes on the painting side are:
The main changes on the printing side in QtPrintSupport are:
There have also been numerous other bug fixes and code clean-ups with more on the way, of particular note Windows printing now positions text correctly in relation to graphics.
An important note for Linux packagers is that QtPrintSupport now requires CUPS 1.4, which most distributions have been using since at least 2009, but this does mean that RHEL 5 will no longer be supported by QtPrintSupport. Optional support for CUPS 1.6 is planned for Qt 5.4.
These changes in the backend are obviously significant, especially the full re-write of the platform code that talks to the physical print devices. While the code has been tested on a number of major-brand printers, the sheer variety of print devices and variable quality of print drivers (especially on Windows) means we need your help with the Beta to make sure there are no regressions or crashes. In particular, I'd like some real world testing on printers attached to remote print servers.
So how can you help? If you use the binary downloads, then you will need to build and test the examples found in widgets/richtext/textedit and widgets/painting/fontsampler, or just test with your own app printing code. Check that the print dialog works correctly and the printed and PDF output appears as you would expect for all printers you have available.
If you build your own Qt, then you can run more tests. Firstly, use either Qt 5.2 or Qt 5.3 Alpha 1 to print out some "Before" documents for comparison purposes. Run the following test/example code at different page sizes and on all your available printers, as well as printing to PDF:
Next copy the output of the following test to somewhere safe:
Finally, run the main auto tests to make sure the old code passes testing with your printers (if you have multiple printers you'll need to set each one to be default before running the test for it):
Now build Qt 5.3 Beta 1 and repeat all the above steps, as well as the following new tests:
Look at the qprintdevice_dump output: do all the reported details look correct?
Play with the manual print dialog test: does changing the page sizes and other settings work, especially custom pages?
Compare the Before and After samples, easiest done by overlaying one on top of the other and holding it up to a bright light. There may be small differences, use your judgement to decide if they are better or worse.
If you have previously reported print layout bugs, then please retest these. If you have your own code or app that uses printing then you can also test with that.
If you find any problems, then please open a bug at bugreports.qt-project.org and attach the output from all of the above, both before and after, and if possible scans of any printouts that look wrong to you.
In Qt 5.4, free time permitting, I'm planning to improve our support for print job and print settings management, and in 5.4 or 5.5 introduce support for cloud and mobile print services. I'm also looking at what bug fixes can be back-ported to Qt 4.8. If that's something you'd like to be involved in, or your company might be interested in sponsoring development of, then drop me a line and we can get coding.
Just a reminder we still have sponsored tickets available for Qt Dev Days in Berlin in October, and a limited amount of travel and accommodation sponsorship to help you get there. See my previous blog for details.
If you've already emailed me and haven't heard back then I can only apologise and ask that you please email me again. Unfortunately my web host decided that I was a spammer and suspended some of my email accounts, and in their wisdom then informed me by emailing an account they had just suspended... A week later I finally noticed I was only getting 20% of my usual email volumes and managed to sort the mess out. Perhaps it's fate telling me to migrate to MyKolab :-)
***UPDATE 2013-08-27: KDE e.V. has now approved travel and accommodation sponsorship for a limited number of ticket applicants. If this would enable you to attend, please email me requesting a ticket, quoting your expected travel expenses and indicating if your attendance is dependent on the travel sponsorship. I want to submit the list of applicants for approval next Monday, 2nd September so please contact me before then.***
Qt Developer Days Europe 2013 is coming on October 7-9 and once again this year this KDE e.V. is partnering with Digia, KDAB and ICS to help organise and run the event. In particular, KDE will be organising the Qt Contributors Day on October 7, and will be running a KDE booth to promote the KDE community and our software offerings.
A major focus for the Qt Contributors Day is the ongoing contributions by the KDE community in Qt and preparation for KDE Frameworks 5. However any major topic related to Qt development is welcome to be discussed, whether code or community or governance related, especially where contributions can be sought from the KDE community. If you're attending Qt Dev Days and want to attend the Qt Contributors Day, then please register your interest on the wiki page. If you would like to volunteer some time on the KDE booth while there, then please email me, or see me when you get there.
One benefit of KDE e.V. being an official partner of Qt Dev Days is that KDE e.V. is able to offer a very limited number of sponsored tickets to Qt Contributors Day and Qt Dev Days (excluding the Training Day) for active KDE contributors. These tickets are obviously very valuable and we would like to see them used to gain the maximum benefit to the KDE community. We intend to allocate the tickets evenly between key developers who need to attend the Qt Contributors Day, regular developers wanting to stretch their skills, and promising new contributors who want to dig deeper into Qt.
In return, all recipients of the sponsored tickets will be required to assist in the running of Qt Dev Days. These admin tasks are not very onerous and will leave plenty of time to attend the sessions: they are mostly running the registration desk at the start of the day and the KDE booth at various times during the day. All tasks will be rostered in advance with some flexibility to swap slots if needed, but all ticket recipients will be expected to do their fair share of the work, and to properly represent KDE while doing so. Unfortunately the KDE e.V. is unable to offer travel or accommodation sponsorship at this time.
If you want to apply for one of the sponsored tickets, then please email me at email@example.com with a description of why you want to attend and how you think KDE will benefit from your attendance.
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:
The QDateTimeFormatter and QCustomDateTimeFormatter classes support the following styles:
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.
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:
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:
Future features I'd like to see:
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?