frameworks and applications

The words we use matter, as they often shape not only how one does think about things but also how one can think about the subject. This is because the words we use can lead to excluding some valid options and including invalid ones.

In past releases of the KDE software compilation, right back to when we called it all just "KDE", whenever library development needed to enter a major release cycle (e.g. 2.0, 3.0, 4.0), everything entered that "big change" phase. This included the applications, the desktop, etc. This worked pretty well when the number of applications were low and the overlap between "people who work on kdelibs" and "people who work on applications" was very high. It ceased working so well by the time we started working KDE Platform 4, however.

Application developers either started porting "too" early or "too" late. Some jumped on the 4.x bandwagon quickly and suffered constant API drift, while others waited until "it" (whatever that meant) was stable (whatever that meant). Our users, in the meantime, drummed their fingers waiting for applications and workspace that they could use to be released. The need to get releases of applications out to users put unnecessary pressure on the library development process as well as the workspaces. They were all "welded together" in terms of release management. This reflected how we generally thought of the KDE codebase in general.

At the recent Platform 11 event, we allowed ourselves to really take on the implications of KDE releasing a Platform, Workspaces and Applications as seperate things. It was no longer evident that we had to put application development on pause while library development happened. It was no longer evident that "our" libraries were only for "our" applications.

This in turn allowed us to see our libraries as a collection of powerful, well-integrated, co-supportive frameworks. We started identifying "platformy" bits that had been added over the years and worked on clearly defining what the individual frameworks really are.

The plan that was proposed and accepted at Platform 11 is to start work on the next major version of kdelibs, kde-runtime, kdepimlibs, kdepimlibs-runtime and kdesupport immediately once 4.7 is ready. These modules will be morphed into a clearly defined set of libraries and runtime components with an emphasis on modularity.

We won't be waiting for Qt5, though we will be tracking the development of it closely. When Qt5 is a viable library target then we will change our Qt dependency for Framework development to that. We also are not targeting large new blocks of functionality as we did in the 4.0 release when we took on the major (and necessary) additions of libraries such as Solid and Phonon.

This will allow us to do the Frameworks organization first, influence and participate in Qt5 development as it happens and then take on Qt5 when it becomes ready all in a timely manner. At that point, application developers can begin to decide working on adopting the updated Frameworks as we work on final stabilization.

In the meantime, releases of KDE Workspaces and Applications 4.x will continue on as they have for the last few years: every 6 months. Our work in the Frameworks will not get in the way of those regular releases, preventing application developers from getting stuck between making releases now and jumping into the new versions of the libraries.

For application developers, this means as little disruptive change as possible: the functionality you have come to rely on will remain and in the meantime your releases will go unhindered. Modular libraries means more git repositories, but we will be providing an easy means to "build 'em all at once" just as we do now while allowing for "cherry picking" the specific libraries that you want to use in your application, complete with clarity in dependencies and separate git repositories.

For users, this means you will still get updates to your applications while the Frameworks hacking goes on. No more "great pause" in releases while Qt and KDE library hacking goes on as it did in 2.0, 3.0 and 4.0. It will also allow applications and the workspaces to release once the Frameworks are ready at a pace that allows for great stability and utility on first release.

To coordinate our efforts, the team at Platform 11 came up with solid definitions, detailed listings and clear graphs to guide us. They have been sent for further input on kde-core-devel to include everyone in our community. Branches in the Frameworks modules will start soon (pending 4.7.0) and work will move into full swing. All without nary a ripple in the application development efforts.

This is possible because we have gone from a monolithic mindset, which reflected the successful realities of early KDE releases, to one that reflects the realities of today: we release Frameworks, Workspaces and Applications .. and lots of them. They all rely on each other, work amazingly well together, are derived from the same enormous and vibrant community, but are today much more independent pieces of the whole.

Our ultimate goal is simple: to increase quality as we catapult our libraries into the hands of ever more developers ("Qt-only", mobile, ...) in a timely fashion while minimizing disruptions to our users.

Frameworks, Workspaces and Applications ... Words are, indeed, powerful things.

kdenlive

One of the other nice little bits of news that was shared at the Randa Multisprint: Kdenlive, a terrific video editing tool that is Free and Open Source Software built with Qt and KDE technologies, is getting a little closer to the KDE community. Not only did Kdenlive developers join us here as part of the multimedia sprint (which is the fabled ".5 sprint" you may have seen referenced in other blogs, but Kdenlive will be hosted in the KDE infrastructure. I look forward to running `git clone kde:kdenlive` and watching our community grow larger and more diverse as we lower the barriers between different projects.

Go kdenlive! :)

dissections

I'm sitting in the games room where the fußball tournament, which has replaced the trip to Zermatt which was canceled due to weather, is in full swing. Eight teams vying for the win, with laughter all around. Still, four people in the room here are hacking while most of the attendees remain scattered about in the rooms in the three floors above us working diligently. On what, you ask?

Well, there is the multimedia group working on the next generation of Phonon and Amarok (there's a PulseAudio fellow here with them, so that's also getting attention), there's the KDevelop group hacking on making it awesome (there's a new Plasma dashboard for it, too!) and the Semantic Desktop group (Nepomuk, Zeitgeist and Plasma devs) going mad on improving the infrastructure and implementation of those technologies and working on how well they integrate with each other. While we had a series of lightning talk updates from each group yesterday, I'm still not up to date on all the details of each group. Even though I visit them during meal times and occasionally in the day, there is too much going on and I'm too busy with Platform 11 to be able to blog about those events in detail. I'll leave that to those attending those events. :)

So what have we been doing at Platform 11? In short:

• Working on what we want the relationship between future Qt and KDE's libraries to be. We will be sharing our ideas on the mailing lists as we finish documenting them.


• Preparing for the inevitable coming of Qt5 by going through each class in kdelibs, yes all 200+ of them, and cataloging where they belong in the scheme of things. This might include targeting inclusion or integration with Qt, refinement or deprecation. We are aiming for source compatibility as much as possible, however, just as Qt5 is.


• Cataloging each and every item in kde-runtime (all 102 of them, according to our spreadsheet) and dividing them out into function. Let's just say that runtime will become a lot smaller and properly focused in upcoming releases.


• Examining our existing library solutions and determining what to do with them. There is likely to be a significant, mostly source compatible, change to KConfig, for instance. A SecretService based internal overhaul of KWallet has also been seeing considerable progress here.


• Working on the git workflow we want to use for the libraries, runtime and workspaces (and hopefully as many other KDE hosted projects as possible). Cornelius just finished up the draft proposal and Frederik has done some graphics for it as well. It should make its way to kde-core-devel in short order.


• As an extension of the latter, our release cycles have been discussed at length and consensus has been reached here in person. We will be sharing those results on the mailing list as well, and I don't want to blog about them until that occurs so that other contributors may be involved first before bringing the ideas to a wider audience.

In short, a lot of hacking, a lot of meetings and a lot of progress. The biggest amount of effort has gone into the careful dissection and examination of our platform in the light of what we've learned in the last few years, the coming of Qt5 and new frontiers both on the desktop and in consumer electronics.

The gorgeous mountains here in Randa have served to provide inspiration to our efforts and the sprints have already produced significant results. It's been great to see so many new people here (something like 1/3rd of the people were attending their first KDE sprint!) including some of our friends from communities such as GNOME.

A string of article for dot.kde.org will be written once things wind down here. The first people have begun to leave, and the exodus will continue over the next few days. It's always sad to see our friends and collaborators leaving, but being able to spend this time with them has been priceless. :)