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 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.
Ana posted a good blog about small KDE3 applications missing in KDE4 which spawned some good comments and suggestions for more apps that we are missing. Rather than let such ideas disappear into the ether I've created a wiki page for Missing Applications to try keep track. So if there's a KDE3 application that you are missing in KDE4, or a Gnome/Mac/Windows app you'd love to see a KDE4 version of then feel free to add it. Please don't just dump a list of random application names though, do a little research first to find out what the status is, what alternatives already exist and what would be the best way to do it.
Related to this is "Finding The Unloved" which the Community Working Group runs every now and then to find applications and projects that are struggling and need help, or are now unmaintained. I've also created a Finding the Unloved wiki page for keeping informal track of those. The page has separate sections for apps and projects that are requesting help, and for apps and projects the community has expressed concerned about. Please do not add anything in either category without first checking with the project or application involved, and always add a status date for your entry to help keep track of things.
While cleaning up the TechBase Getting Started pages for the Git move, I've been noticing a lot of other pages that are either incorrectly located in the TechBase hierarchy, are lacking in quality or detail, or just don't belong there at all.
So, before you add anything to TechBase, ask yourself two key questions:
So how do you decide if stuff belongs on TechBase? In KDE we have three main wiki's serving three different purposes:
Where the difference lies between TechBase and Community for Project documentation can be tricky, but I think of it as roughly along the lines of Stable versus Unstable.
TechBase is the formal stable documentation, how we do things, how external parties can use what we produce, stuff that a project's external technical users need to know. It is facing outwards.
Community is the informal unstable documentation for internal consumption only, what a team is planning to do, how they are going to do it, meeting minutes, stuff that a project's internal development team needs to know. It is facing inwards.
So documenting how someone outside your team can write a plugin for your application goes to TechBase, documenting how your team designs and builds that plugin infrastructure goes to Community. TechBase will usually only change after a release, Community will constantly be changing.
So where to put stuff in TechBase? If it affects KDE as a whole, add it at an appropriate place under one of the existing top-level sections. If it just affects a single module or project within KDE, then add it under the Projects top-level section, organized by Application or Module as appropriate.
Please don't start new top-level pages.
Here's the current top-level sections to choose from:
(Yes, some of those top-levels could be moved lower down the hierarchy).
We still have a lot of community related content under TechBase Projects, it would be great if projects could put aside a couple of hours to clean up their TechBase entries and move community related material over to their pages on Community. It might also be useful to add reviewing of your TechBase and UserBase pages as part of your pre-release check-list so your technical and end users are able to find up-to-date information.
One nice feature of Git is the ability to configre a default Commit Message Template that appears for you to edit whenever you create a commit. This enables a project to display reminders about how messages should be formatted (e.g. wrap at column 72) and about details to be included (e.g. BUG: keyword). I've just added the default KDE commit template to kdelibs master and it would be great if people could configure their git settings to use it by default. The template also includes a new DIGEST: keyword to let the Commit Digest team know you have something interesting for them to write about.
You can find instructions for setting it up at the KDE Git Configuration page, along with other configuration options and bash magic that we recommend people use. We also have a KDE Git Recipes page where we are collating some simple step-by-step recipes for people to follow when first starting with Git in KDE, if you have any to contribute feel free :-) I've also been re-writing many of our Getting Started tutorial pages to cater for the brave new Git world. They're by no means finished yet, but hopefully they'll be more useful once done.