I’m on my way back from the Randa Meetings, where a few teams in KDE came together to collaborate on the next steps in their respective subprojects. I’ll post this to my blog after arrival, but as I’ve got some time to kill here in Basel, Switzerland, close to the German border, I decided to recap what we’ve been up to in the past days. I’ll concentrate on what the Plasma team has been working on. Present were Marco, Aaron, Afiestas, Giorgos, Antonis and myself. Giorgos and Antonis are still relatively new to the Plasma team, they concentrate on on making Plasmate rock, but have also done some excellent work this week on libplasma2. I’m happy to see the influx of enthusiast and skilled new developers in the team, as that reduces the busnumber and makes it easier to achieve our audacious goals.

Speaking of goals, we came to Randa with the plan to achieve a critical mass towards libplasma2. But what is libplasma2 exactly? Well, while we had some plans where to go with it, there were still a few items unclear — but not anymore! One of the big ticket items was the future of QGraphicsView in Plasma. QGraphicsView had been introduced in Qt 4.1. It’s basically a canvas on steroids, that gained features to create a fluid, widget-based UI using it. In Qt4, QtQuick uses QGraphicsView as its rendering backend. QGraphicsView is heavily based on QPainter, and employs a procedural way to rendering the UI. In Qt5 and QtQuick2, graphical display is supposed to move to an OpenGL scenegraph, making it possible to move much of the work involved to display a UI into hardware, so your GPU can do its magic with your UI. The benefit for the user is mainly that we’re able to have a much better performing rendering engine underneath (so smoother graphics), and more CPU time left to do the real work of your application. (One side effect will likely also be that we save a bit of power on mobile devices, as the GPU is much more efficient in doing these tasks – it has been optimized for it. (Experts say that the saving is in the range of an order of magnitude. Wether or not it will be noticeable to the user in the end, we’ll have to see later.)

As the OpenGL-scenegraph-based rendering is an entirely different paradigm compared to the procedural QGraphicsView, we have to rethink our use of QGraphicsView. Unfortunately, QGraphicsView is deeply ingrained into Plasma’s architecture. Even more unfortunate is that it’s not as bugfree as we’d like it to be, in fact much of the occasional rendering glitches you sometimes see in Plasma-based UIs are caused by QGraphicsView problems. Moving away from QGV and towards scenegraph is likely to solve this whole class of problems.

So one thing is clear, we want to move towards scenegraph. But what about all the old, QGraphicsView-based code? Well, we already started moving components of Plasma Desktop one by one to QML. This has begun with Plasma Workspaces 4.8, a lot more has moved in the 4.9 cycle, and yet another batch will move with 4.10, which will be released in January 2013. Our credo has been that we want to ship feature-equivalent ports, in order to keep the impact for the user as minimal as possible. There will be a point, however, when we will have to remove support for QGraphicsView in libplasma, and that will likely be libplasma2. We expect this work to take still more than a year, so also third party developers get ample time to move their code to the (much nicer) QML way of doing UI. But why not keep support for QGraphicsView? Well, it’s not that easy, as scenegraph and QGV are due to their respective paradigms more or less mutually exclusive. We’ve spent quite some time trying to come up with solutions that guarantee maximum amount of backwards compatibility, but we also had to ask ourselves if we have the manpower to implement and maintain workarounds for the incompatibilities between scenegraph and QGV. Moreover, what would the impact on our APIs and our code be? the tradeoffs were quite horrific, so in the end we decided to bite the bullet, and remove QGV from the frameworks5 branch. But what will Plasma2 with out QGraphicsView become? What we came up with is actually a very neat and clean approach: Our classes that currently manage the workspace (Corona, Containment, Applet) will become abstract managers that concert how components work together. Containments and Applets will have their UI written in QML (so we can do the rendering in the scenegraph, thus in the graphics hardware). They are extensible through C++ and various scripting languages that have bindings for Qt. This way, you can choose to implement the business logic in your favourite procedural language (C++, Python, Ruby, QtScript, etc.) and do the UI in a declarative way. Things like theming, localization, distribution, and all that will still be offered by the platform.

In Marco’s preliminary branch, where he removed support for QGraphicsView from libplasma2, the result is quite spectacular. The library is already about 30% smaller, and will likely lose another big chunk of code. That means more maintainability, a smaller memory and disk footprint and faster startup. As the functionality of QGraphicsView is more or less a subset of what we can do with QML, it’s not any less powerful or flexible. Just smaller, leaner and meaner (and also a bit easier to grok for developers using our APIs).

As you can see, we have been quite productive during this year’s sprint in Randa, and the above is only one part of what we’ve worked on. We’ve also made quite a dent into our TODO list for the KDE Frameworks 5 port, reviewed lots of patches, fixed bugs left and right, made existing code faster, and caught up with each other on various side projects. This all would not have been possible without the sponsors of the event, and the 287 people who donated through our fundraiser campaign to make this great event in a scenic location possible. Thank you all!

The discussion around including online search results in the workspace, and especially in the app starter, reminded me of a discussion we had some time ago about including online search in KRunner queries. First of all, I think the idea of including online search results directly in the shell is great. It’s not new by any means, but it serves value to the user, and in fact, I use it daily and would not want to miss it.

In KDE Plasma, we do that for a few years already. I recall sitting down during the Gran Canaria Desktop Summit in 2009 with Richard Moore and hacking on a KRunner plugin that includes results from Wikipedia and Wikitravel in the KRunner search results. We got that working pretty quickly, and the plugin is shipped on most installations of Plasma Desktop out in the wild nowadays, and nobody complained. How come?

Privacy by Default

First of all, we do it quite differently from the way Canonical does it in Ubuntu. Sending every search query to an online service forms a privacy problem. Especially when not using SSL encrypted HTTP requests, people around you can basically wiretap your traffic almost trivially, or intercept it using man-in-the-middle-attacks. Also, the service receives all your queries as well, not something I’d want in general. Even if I trust someone in principle doesn’t mean I have to tell them everything I do.

While we ship plugins that promote Free culture (in this case Wikipedia and Wikitravel), one could easily add support for Amazon as well, and of course for all kinds of search engines. (We do include a couple of proprietary web services in KDE, but we’d never silently send them data when it’s not clear to the user or explicitely asked for) What we, as Plasma maintainers will not accept however, is triggering these online requests on every query typed. Basically, we won’t send anything across the net without the user explicitely requesting us to do so.

Maybe we could raise some funds this way, but we think that our users are best served with a system that gets advertisement out of the way. I’m personally easily annoyed by commercial offerings which jump into my face without me asking for it, and I understand I’m not the only one.

Earning Money through affiliate programmes

A few months ago, David Faure, the maintainer of Konqueror, KIO and a lot of other important pieces in KDE got contactetd by the DuckDuckGo search engine. DuckDuckGo asked if KDE would be willing to take part in their affiliate programme. David passed this on to KDE e.V. and offered to do the necessary changes on the code side if we decide to go ahead with this. DDG offered us to receive 25% of their earnings per clicked ad when the user searched through Konqueror (or in fact through the webshortcut). As we have already been shipping a search provider for DuckDuckGo for quite some time, it was enough to add KDE to the search query and sign a form with KDE e.V.’s banking details. That’s some free money, maybe not much, but who knows and every bit helps. The impact technically and to the user is minimal, and it didn’t require any changes to our privacy principles and setting, so ahead we went.
That means, if you feel like supporting KDE through your online search, that’s easy: Use the ddg: search provider (see below). This works starting with 4.9.0.

Online, but respecting privacy

So, offline and private by default, but how can we still include all the goodness from the Internet in your local search results, so we save you a trip to your webbrowser when we can? There are a few ways you can easily query online services from your desktop:

• Wikipedia, Wikitravel (and other MediaWiki-based services): ALT+F2, enter “wiki $YOURQUERY”
• Videos on Youtube: ALT+F2, enter “videos $YOURQUERY”
• Google search: ALT+F2, enter “gg:$YOURQUERY” (use ggi: for google images, dd: for DuckDuckGo, amz: for Amazon, qt: for Qt API documentation, php: for PHP docs, many, many more are available as well, have a look at Konqueror’s webshortcuts for a full list, all of those are transparantly supported in KRunner as well)

Please have your cake, and eat it, too! :-)

Randa Retraite

Starting this weekend, KDE e.V. the organisation supporting the KDE community organizes a number of meetings in Randa, Switzerland. Randa is a village in the Swiss Alps. It’s a bit of a remote location between mountains which reach up to 4500m, provides the perfect location to sit down together and do nothing but concentrate on a single topic. You can help us to make this happen, but first, read on to understand what we will be doing in Randa, and why.

From Platform to Frameworks

One of the meetings planned there is the meeting of the KDE Plasma team. The goal of this meeting is to plan and make progress on the port of libplasma, the framework that is underlying the Plasma workspaces to Qt 5 and KDE Frameworks 5.

Within the KDE Frameworks 5 effort, the KDE team splits up and reorganizes the whole KDE platform. This effort has been started during last year’s meeting in Randa, and while being a huge effort, we have already made good progress across many of the libraries and technologies that make up KDE Frameworks. KDE Frameworks 5 will be mostly source-compatible, meaning that no large rewrites will be needed in order to port an app to Frameworks 5, much rather, we’re splitting dependencies differently across the board to make it easier to reuse only certain frameworks, without having to drag in larger dependency chains. The Frameworks 5 effort goes along with porting of the codebase to Qt5 (which is also much more painless than the port from Qt3 to Qt4). The result will be a faster, more modular, and hopefully due to these new virtues more widespread use of KDE technology.

The road to Plasma-Next

One of the technologies in Frameworks 5 is libplasma2. For libplasma2, there is still a lot of work to happen. While we have a rough plan what we want to achieve, and already taken the first steps to make this happen, there’s still a huge mountain of work ahead of us to create a new libplasma2 that is worthy its place in Frameworks 5. One of the high-level goals is to be able to run Plasma workspaces (and apps) in an entirely hardware-accelerated environment. In Qt5 terms, this means we want to use QtQuick 2 to display our user interfaces using an OpenGL scenegraph. As that is quite a deviation from the current, QPainter-based approach, you can imagine that it won’t be easy to get this “just right”, and in any case, it involves touching and testing a lot of code that works well right now. Also for Plasma Addons, we want to achieve almost source compatibility, so all the work that has gone into Plasma in KDE SC 4 will be immediately available in the new world order of Qt5. Not an easy task, and there are a few areas where we don’t have satisfactory solutions yet. A lot of sweat and braincycles will be needed.

The good news is that we have a capable and motivated team to tackle this effort, and to really kick off our libplasma2 hacking spree, we will sit down in Randa and plan all this through in detail, then sit down and get hacking so we have hopefully reached a critical mass to continue on, and a clear and shared vision across the team how we want to go about the remaining work.

How you can help…

Free Software is a joint effort, and everybody can pitch in. In order to get travel costs funded for this event in the Swiss Alps, we have started a fundraiser campaign. The goal is to raise 10.000€, and we’ve already made good progress towards this goal. You can help reaching it, making the sprint in Randa possible and contribute to the future of the software you might (or might not yet!) be running!

So with the Apple vs. Samsung case drawing to a close, we’re all being reminded how bad patents are, for developers, for innovators, and also for consumers. I’ve written about Defensive Publications as a means to fight the war on patents before, and while reading the news this morning, it’s probably time to give everybody around a few hints how to best write a defensive publication so that, at least that idea, cannot be patented and used in the war again.

A defensive publication is a technical document that describes ideas, methods or inventions and is a form of explicit prior art. Defensive publications are published by Open Invention Network in a database that is searched by patent offices during a patent exam. A good defensive publication will prevent software patents from being granted on ideas that are not new and inventive.These will help protect your freedom to operate.

A defensive publication typically consists of the following:

• a descriptive title
• a few paragraphs documenting the idea including how the idea would work.
• one or two (or more) diagrams describing control flow, interaction, network flow or communication between components possibly an example or two

It is important to make sure that a defensive publication does not go into too much detail: patent examiners typically have little time to read all materials and it makes it likely to miss the important bits. If possible only describe one idea or invention per defensive publication. If there are two or more ideas that can be conceptually separated, split them and write them as separate defensive publications.Make sure that the defensive publication connects completely describes the idea by explaining HOW this idea would work. This part is the most important. Without the how, the idea is too abstract.

Things to watch out for when writing defensive publications:

• don’t use technology specific terms, like program names. For example: don’t say MySQL, say database.
• don’t refer to competitor’s products, or say that it works like a specific technology
• try to use standard terms that are in common use

Examples of defensive publications can be found on IP.com. Via the “search” menu a menu for “non-patent literature” can be found. The publications sent in via Linux Defenders can be chosen in the drop down box for prior art databases.Good places to scrape for ideas for defensive publications:

• roadmap
• blog posts
• issue tracker (especially wish lists)

Tools for making the diagrams:Good tools for making the diagrams are:

• xfig (very basic)
• scribus (for a limited set of diagrams)

If you’re interested in how this could look like in practise, have a look at my example defensive publication on KDE Plasma’s Activities.

Much thanks go to Armijn Hemel, Andrea Casillas and Raffi Gostanian from the Open Invention Network for helping me collect these tips.

Software patents are an evil thing which should die a horrible and painful death. Until that moment, recording prior art in a way that is understood by the system is an effective way to fight patents. By recording prior art in the form of defensive publications, we can make it much harder for a patent to be granted — and it does not have to be hard at all to do so.

Yesterday at FISL, I attended a panel on software patents in Brazil, the discussion revolved around the why and why nots. Unsurprisingly, there are a lot of good reasons why not, and very little pro. It’s an interesting topic, especially since I lately dived a bit deeper into this topic. Softwaree parents were also high on the agenda of this year’s Akademy, which happened last month in Tallinn, Estland. They are legal threats to Free software, so we need to figure out how to deal with them. Let’s first rehash why software patents are a bad thing:

• Patents are valid for a ridiculously long time. This unrealistic timeframe makes them effectively stifle progress
• For a casual developer, it’s impossible to know if she or he is infringing on any existing patents
• Software patents are used in entirely wrong ways: Often patent claims are brought in after a product has shipped successfully, so in order to protect prior investment into research, they’re used as weapons of economic warfare.

So, software patents are bad, really, really bad. Unfortunately they are just as well a reality we will have to deal with for the foreseeable future. Make no mistake, software patents should not exist, they are evil and they should die sooner rather than later. Until then, however, the threat is real and needs mitigation.

The process of creating a software patent is, very roughly: You come up with a new idea, you write it down in a formal way, you register it with a patent office, the patent is reviewed and rejected or granted. One part of this review process is research for prior art. In order to grant a patent, it has to be an original idea, and it must not already exist.

The “must not already exist” is also known as prior art. Prior art must of course be known, so it has to be visible in the public space. Prior art that is useful in the War on Patents is right under the nose of the reviewers at the USPTO (U.S. Patent and Trademark Office), for example. In order to prevent patents from being registered, having as many technologies, ideas and concepts as possible registered as prior art is an effective way to fight the system with its own weapons.

The Open Invention Network sent us three smart people to Akademy, which was really useful. Apart from being cool folks, the OIN’ers also presented us a relatively easy way to record prior art as “Defensive Publication” and feed it into the system so it will be found, considered, and lead to rejection of similar patent applications. The nice thing here is creating a defensive publication is a lot less work than applying for a patent, it is in fact very well doable for an individual developer. A typical defensive publication fits on one page, has a few paragraphs of text with a generally applicable explanation of the idea and preferably a diagram or graphic that makes it easier to understand it. The key here is that it should be easy to understand for an alien to the specific technology (but technically savvy person nevertheless) to understand and find back in the case a related patent application ends up on the table.

There’s a few pleasant catches to this whole thing:

• The process is lightweight, with a bit of exercise, writing a defensive publication about a good idea can be done in half an hour
• The idea you’re recording doesn’t even have to be your idea: You can help a fellow developer by recording his work in this form. As you don’t derive any kind of license or copyright to the actual work by writing the defensive publication, the work can be spread.
• The idea does not need to have been already implemented. Just being able to prove “somebody has already come up with that!” is enough, so even (consistent) brainfarts are eligible

By now, you might already get why I’m writing this: In order to effectively fight the war on patents, we need more people to write these defensive publications. As it’s quite easy to do and we have people who help us in this, I’d like to encourage you all to record prior art we’ve created.

Update: I’ve uploaded an example defensive publication of prior art about Plasma’s Activities, find it here.

After a nice stroll through downtown Porto Alegre with a few fellow Free software activists from Spain, Mexica, Peru and Argentina, today was the first day of FISL13, and it was amazing. My usually screwed up biorythm in this part of the world means that I get up at a reasonable (for a conference visit) time in the morning, enough to have a relaxed shower, a bit of emailing, breakfast and still be on time for a fully packed conference day. FISL’s first day was amazing, it started off by meeting a few well known faces (Sandro, Filipe, Isabel, Knuth, I’m talking to you!), and getting to know a lot of new ones. Especially the Brazilian KDE community is really awesome (I knew that, but doesn’t hurt to mention it nevertheless). I also went by SOLAR, the Argentinian Free software organisation who offered me a nice cup of Mate tea, and an opportunity to share some ideas by means of an interview.

After a bit of booth-crawling, I went to attend two talks, which were both really excellent: The first was by Seth Schoen, who is with the Electronic Frontiers Foundation (EFF). Seth talked about privacy and data security at the United States Border. I’m sure anybody who has travelled to the U.S. in the past 10 years can relate to that. Seth explained how the border control is organised, what your right are (at the border, your normal civil rights are actually limited, so searching your luggage or detaining you for questioning can be done without good reason, unlike “in the streets”, so it’s very good to know what they can and can’t do), and how you can protect yourself in case you *DO* have something to hide (or rather, how you carry private information on digital devices across the border). There are a few methods, one is: wipe your device, do a clean install and download the interesting data only after you crossed the border, more sophisticated tricks involve temporarily encrypting your device with a key you don’t know and only get after you’ve passed through border control. Lots of interesting information there, and it makes me more comfortable when travelling to the U.S. the next time. Also, chapeau to the EFF for their protection of privacy and civil rights in general. The talk was excellently held, really interesting and absolutely worth my time.

Next up was Rick Falkvinge, one of the founders of the first Pirate Party (in Sweden). Rick talked about the history of copyright, how people who gain power all of a sudden “kick away the ladder” to secure their position, and how, in more general the Internet changes society. Another excellent talk that felt like it was really worth the time spent. Interestingly, these days, the Brazilian branch of the Pirate Party is being founded, so it’s very much a historical thing happening here. Excited to witness that.

Later in the afternoon, Daker Fernandes Pinheiro of Plasma Qt Quick Components fame and me did a workshop teaching everything you need to know to get started writing device-adaptive applications using Plasma. The workshop was well-attended, I think well prepared as well and people seemed to like it (even if we flooded everybody with a lot of information). It was quite practical, luckily Daker and me hit the right audience, so I think even if it was quite heavy on information, it’s still manageable. After a good two and a half hours where we taught the basics of Qt Quick, Plasma Quick, and how to write Plasma Components and Apps, it was evident on the faces of our audience (and judging by their questions) that people enjoyed our sharing of knowledge, and who knows, maybe a few of the attendants will join our team and become new KDE hackers. As promised, I’ve put the slides online. They provide a good overview of the technologies involved, so are probably quite useful as reading material. Of course, as sharing is good, let me know if you would like to reuse them in part or as a whole, and I’ll send you the sources (including a bit of example code). I myself enjoyed “teaching” as well. Especially Plasmate, our one-stop-shop workflow-driven Plasma IDE resonated really well with the audience, just in time for the end of this summer’s 1.0 release.

Overall, I’m really exhilerated by FISL so far. People are more than welcoming, so it immediately feels “at home” (at 12.000km away from it!), I’ve had really interesting and inspiring conversations, and everything is really well organised. I’m now at my hotel (one that focuses on sustainability, it’s really nice, well done FISL peeps!), we’ll go for churrasco in a bit and then off to the first night’s party.

My talk on “Freeing the Device Spectrum” will be on Friday, at 11.00 o’clock in the GNU hall (that’s the big auditorium). It’s targeted at a general audience, so a lot less technical than the workshop we did today. Be there, or be square!

I got up rather early this morning to catch a flight from Amsterdam across the ocean (and equator) down to Brazil, where on Wednesday FISL (Forum Internacional Software Libre) will start. Right now, I’m temporarily stranded in a bar at Sao Paulo airport, waiting for my connecting flight to Porto Alegre where FISL will take place.

Already a few years back, I heard that FISL is one of the pearls among international Free software events, and this year, fate (impersonated by the FISL organizers) invited me to speak at FISL, a wonderful opportunity. Doing bit of research, FISL is an order of magnitude bigger than European events, which due to geographical proximity are a bit more often on my agenda, so I’m quite excited to celebrate this Planet’s biggest community-driven Free software event, and I’m honoured that I will get the opportunity to present our ideas, work and progress on Freeing the Device spectrum to the audience (mark down “Friday, 27th, 11.00h, auditorium” in your agendas!).

Brazil has a special place in my heart, I’ve been working together for a few years with many awesome Brazilian hackers and contributors, I’ve had the opportunity to visit this huge country earlier (when I keynoted at OpenBossa conference in 2009 in Recife) which I’ve fond memories of. I’m glad I’m back now. (Although it’s not quite so real yet, airports are quite the same everywhere.) I’ll arrive at my hotel in Porto Alegre quite late tonight, will hopefully get a good night of sleep to counter the jetlag, and a day tomorrow to acclimatize and possibly visit the city.

On Wednesday, Daker Pinheiro and me will be running a workshop about developing apps for the device spectrum using KDE technologies. For this workshop, no prior knowledge of Qt or KDE technologies will be required, we hope to be able to get you going with the basic steps and concepts during that workshop, so that attendees get a kickstart and can continue this fun adventure when they’re back home, supported by our many online support channels (docs, email, IRC, wiki, read-the-source-luke, etc…)

The weather back home in the Netherlands has been mostly aweful, quite a crap summer indeed. Let’s see if Southern Brazilian winter beats this year’s Dutch summer…

Plasma Active brings a flexible, elegant, activity-driven user experience to a spectrum of devices. This article is part of a series of articles about different perspectives on Plasma Active. This installment looks at the user story, and aims at answering the questions “How do we get developers interested in Plasma Active?”.As I’m quite a bit behind on my series of perspectives on Plasma Active, so let’s try to catch up a bit. I’m trying bit of an experiment Marco and I talked about last night: Using personas not only for user stories, but also for our developer story.

Chad – The Casual Developer

Chad is a 23 year old developer. Chad has basic (but much to his regret not highly advanced) programming skills. In order to manage complexity, he mostly works in JavaScript. Concepts like cross-compiling code, packaging and deployment are alien to him, ideally he can avoid them entirely. Chad’s main interest is to transfer cool ideas for apps he has into reality. Chad does this work next to his studies, as Freelancer.

Chad’s IDE of choice is Plasmate, a simple IDE entirely geared towards creating Plasma addons. Plasmate guides the user to the whole workflow: creating a new app template, coding the app, testing it and deploying it to one or more target devices, and publishing it using online services. By providing these features all in a single tool that is small and easy to install, we maximize Chad’s gain for the brain he put into the code. While Plasmate is (purposefully limited to “pure scripted” Plasma components (such as Plasmoids, apps) it takes away most of the system learning and allows to fully concentrate on the creative process. Resulting applications are platform indepdenent and can easily be installed on test devices, directly from Plasmate. Complexity of the process is reduced as much as possible. The powerful KDE Frameworks allow to include advanced functionality in Chad’s creation, resulting in rich and visually appealing apps.

Lwing – The seasoned app developer

Lwing is a seasoned C++ developer. She has been working on various mobile and embedded platforms, as well as desktop applications. Lwing would like to bring SqueezeIt! one of her own desktop apps to a wider range of devices. For that, she chose Plasma as being the only truely Free and open system in the world. (Yep, shameless, shameless plug :).

Lwing’s way to success involves a bit more complexity. The recommended way is using the Mer SDK and Open Build Service (OBS) to cross-compile her code and get it deployed to devices. The Mer SDK is quite easy to set up and provides a build environment that produces reproducable results and takes away a lot of the complexity (and therefore pain) from the process of deploying an existing app to a new system. Combined with tools such as KDevelop or Qt Creator and supported by lots of excellent documentation, for Lwing, sky is the limit. Lwing thusly refactors SqueezeIt! to strongly separate data, busines logic and presentation. She designs her UI so it scales to different screen sizes, and implements it using Plasma Quick (Qt Quick plus Plasma QML Components). Libraries and development packages Lwing needs are already pre-installed in the SDK, so she doesn’t have to worry about that, other than updating the SDK once in a while from withing using th