30 Jul 2015

feedPlanet KDE

Porting Qt applications to Wayland

During Akademy I hold a session about porting applications to Wayland. I collected some of the general problems I saw in various KDE projects and want to highlight them in this blog post, too.

Starting Wayland

First the basics: how to start a Wayland compositor? Assuming one is using Plasma 5.4 (aka master) the way to start a nested KWin is:

kwin_wayland --xwayland

Important: ensure that you have Xwayland installed!

If you run nested this will open a window, if it turns black, everything works. If it doesn't turn black: contact me (please check whether you use free drivers first).

As an alternative you can also start Weston:


If you run into issues with your application running under Wayland, please always test whether the problem is also visible on Weston before blaming me :-P

Starting applications on Wayland

Now we have our black KWin window and we want to get a window to it. There are several ways to start it. As an example I'll use kate.

Environment variable

Maybe the easiest way is to just use an environment variable to switch the QPA platform to Wayland:

export QT_QPA_PLATFORM=wayland

And a Kate window will open on the nested KWin.

The environment variable is set to wayland in our startplasmacompositor script to start a full Plasma on Wayland session on tty.

Command line switch

Every Qt application also has a command line switch to select the windowing system:

kate --platform wayland

Starting applications together with KWin

KWin supports starting applications once the Wayland and Xwayland servers are started. You can add the programs to start to the command which starts KWin:

kwin_wayland --xwayland "kate --platform wayland"

Or to simplify with environment variables:

export QT_QPA_PLATFORM=wayland
kwin_wayland --xwayland kate

Of course it's also possible to just start a Konsole and then launch applications from inside the Konsole. Please note that any key combination with ctrl-key is unfortunately broken when running Konsole as a Wayland application.

X11 Specific code

Many applications have X11 specific code. Being it implicitly or explicitly. So we need to move away from it and in most cases it means also improving the situation on X11 because the solution is wrong.

Opening X connection

A common mistake I saw in Qt applications is to open a connection to the X server. E.g. like that:

Display *dpy = XOpenDisplay(NULL);

Now this code is already wrong on X11 as it opens another connection which is not the Qt display connection. It might be on the wrong head, it might be on the wrong X server. From an integration point of view it's broken.

So the solution is to always use QX11Info from QtX11Extras to integrate with the Display:

Display *dpy = QX11Info::display();

Runtime checks in addition to compile time checks

Before Qt5 the way to support multiple windowing systems was to use compile time switches, like:

#if HAVE_X11
#include <QX11Info>

void doSomethingWithX11()

Now this will crash on Wayland. It will be compiled in, but crashes when running on Wayland. So you need to improve. Let's try:

#if HAVE_X11
#include <QX11Info>

void doSomethingWithX11()
    Display *dpy = QX11Info::display();
    if (!dpy) {

Now this code will also crash! The problem is that QX11Info::display() goes through Qt's native interface and uses the key "display". QtWayland also provides the key "display" and returns a wl_display for it, which gets casted into a void in the native interface and then to Display* in QX11Info and boom at interesting places.

The proper way is to check the platform name:

#if HAVE_X11
#include <QX11Info>

void doSomethingWithX11()
    if (!QX11Info::isPlatformX11()) {

My recommendation is to keep the check in a local variable if the check is needed multiple times as in the end it's a string comparison each time. Ideally you should restructure your code to have platform specific subclasses or similar refactored solutions.

General Changes with Wayland

Now here it becomes interesting: runtime changes. The most important information for application developers is probably that there are no more global window ids.

No global window ids

This has quite some implications for your application. E.g. QWindow::winId() returns an internal incremented number. Neither the compositor nor any other application knows anything about your internal window id counter. Similarly QWindow::fromWinId is not able to map a window id to a QWindow any more. This of course affects use cases like sending a window id through DBus to another process to use it for setting the transient hint. Also it means that KWindowSystem API has a hard time to support the calls on Wayland and in most cases it will just print a warning (this might improve, though).

Setting window icon

On X11 the applications exported the window icon as pixmap data. This is no longer possible on Wayland. Instead the compositor maps the window icon from the desktop file and the application announces the desktop file for a window. In Qt this is done by using the reverse domain name combined with the binary name. The domain name is set with KAboutData and defaults to "kde.org". So for example in the case of kate the desktop file should be called "org.kde.kate.desktop". So please fix the naming of your desktop files. If you want to test please be aware that this requires Qt 5.5 to work properly.

No longer working API

Quite some of the API calls of QWindow cannot be supported by Wayland on default (some of them might work on KWin, but please don't implement against KWin!).
A short list of those API calls I know that they cannot work:

In addition it's no longer possible to grab the image of the screen using e.g. QScreen::grabWindow (most obvious for the case of "root" window). Also warping the pointer using QCursor::setPos is no longer supported. Please note that warping the pointer is also a bad idea on X11 and you shouldn't do that.

In case your application set the Qt::BypassWindowManagerHint on your QWindow/QWidget you need to do some porting as QtWayland doesn't show such windows. Unfortunately that needs a case by case evaluation of the use case and the solution I presented during my Akademy talk should not be applied for applications.

Porting to Wayland

Don't port

The solution to port to Wayland is: DON'T PORT! Mostly your X11 specific code or behavior is wrong and could be solved in better ways. Instead of porting you might want to rethink your problem or change to existing abstracted API in e.g. Qt or KWindowSystem. I have seen many cases where X11 API was used as a workaround by e.g. raising windows, force activating them and so on. If one things about it one realizes that there seems to be an obvious problem. So don't try to port that but rethink your problem and improve not just on Wayland, but also on X11.

But I really need platform specific code

Ok, ok, I get it! Now let's start with the obvious: your code needs to be compile time and runtime checked. Let's start with how to not do it:

#if HAVE_X11
    if (!QX11Info::isPlatformX11()) {
    // here goes the X11 specific code
    // here goes the Wayland specific code

The problem with this code snippet is that X11 support is probably also available when you use Wayland. Also the else part is not just Wayland, but also any other platform.

As I said the proper solution is to make it compile and runtime checked:

#if HAVE_X11
    if (QX11Info::isPlatformX11()) {
    if (QGuiApplication::platformName().startsWith(
            QLatin1String("wayland"), Qt::CaseInsensitive)) {

Be aware that your code might also run on other platforms on Wayland, e.g. eglfs or other custom windowing systems. So don't crash if you don't hit any of the code paths ;-)

30 Jul 2015 10:30am GMT

Akademy Day Trip


The GCC 5 Transition caused the apocalypse so we went out to see the world while it still existed


No Soy Líder, Ahora Soy El Capitán


See Hoarse


El Torre


We will climb this!


David reached the top


Fin de la terre!

facebooktwittergoogle_pluslinkedinby feather

30 Jul 2015 10:07am GMT

Akademy 2015

I'm just finishing up a week spend at Akademy, the annual conference of the KDE community.

AGM lunch break

We started last Friday with the AGM of the KDE e.V., the legal entity that deals with the financial and other legal aspects of KDE.

Working 1

After that, we had two days of talks, and then from Monday onwards we've had "birds of a feather", or "BoF", sessions where people working on or interested in similar things get together to discuss things face-to-face.

I have visions, should I go see a doctor?

It's been great fun, and I've really enjoyed seeing people I've met before again and meeting people I've only known through IRC and blog posts or have never even come across.

Question time

The organising team have done a fantastic job: we've had free busses running from our accommodation to the venue, video recording of talks (which I'm sure someone will post about soon), easy to access food, two parties and people always on-hand to provide information.

Smart Tech and Sensible Tech

There have been announcements of new technologies, talks about community things like how to write a vision statement or what artists are doing with Krita, technical talks about things like how to optimise your program, talks about development methodologies and more.

Akademy Award winners

Personally, I've taken the opportunity to start improving our CMake documentation, including writing and planning new tutorials. I've also been working on some Extra CMake Modules things at the request of David Faure, looking at accessibility things with Frederik Gladhorn and trying out the upcoming release of Plasma.


I've had great fun taking lots of photographs this Akademy, and have been uploading them all to Flickr.

Wall sitting

I'm not the only one, either - you can find other photo sets linked from the Akademy wiki.

Find a rock, climb it

I'm about to catch a flight home, but I very much hope I can make next year's Akademy as well.

View from the Torre de Hércules

30 Jul 2015 9:51am GMT

OpenStack Summit Tokyo 2015: Vote for Ceph Presentations

In a few hours the voting period for the next OpenStack Summit in Vancouver ends at 30. July, 11:59 PDT (31. July 6:59 UTC / 08:59 CEST).

Here a some interesting talks regarding Ceph you may would like to vote for (this list is not intended to be exhaustive):

30 Jul 2015 8:58am GMT

Fiber Update

It's been a while since I've posted about Fiber, so here's a brief update.

Sidebar tabs

I've read quite a bit about what people really want to see in a browser and I've repeatedly heard about the disappointment of my tab sidebar decision.

At first I dismissed it because I hadn't really heard of it before, nonetheless know that it's a beloved feature for many. I also wasn't keen on the idea because all the tab form-factors were a horizontal strip and I wanted to (lazily) deal with one orientation.

The original plan was to allow an extension to handle the more crazy form-factors, but as I was blueprinting the APIs on paper I quickly found the tab-bar becoming a nightmarish monster which would have made custom tab extensions painful. Ultimately as a shortcut until a nice API can be made (and many more critical APIs can be rolled out) I'll be adding sidebar tabs as a native feature. I may look at some sort of button form-factor as well, such as the ones commonly seen in mobile browsers.

(We announced flippin' Plasma Mobile, no KDE developer doesn't have phone on the brain!)

With this development though, I'm going to put tab extensions onto the backburner. I'm not completely satisfied with hardcoding something potentially invasive, but in these early stages battles much be picked, and there are other features the tab-bar can gain from that decision.

Performance and Rendering Engines

Before I get into some performance stuff I have on tap, there's an elephant I'd like to address.

I've heard a lot of complaints that WebEngine/Blink/Webkit are "bloated" and resource intensive, and that this selection would inevitably make Fiber a resource-hog browser "like Chrome". I've also heard that Fedora isn't shipping WebEngine, leaving users out in the cold.

On Fedora not shipping WebEngine… I can't say much for that. Programs will start using it, and it's going to be an increasing problem for them the longer they hold out. I won't switch to Gecko, nor will I be providing some sort of "-engine" build switch for Fedora or other holdouts; it's not a practical validation for the time or complexity required to support that, and it would certainly introduce more issues into the browser itself than it would solve for any issues Fedora finds in the engine.

On resource usage it needs to be pointed out that Webkit/Engine/Blink itself is not particularly heavy, and some browsers (like Epiphany) use it and got top marks in simple resource usage tests. Even if the results weren't 100% accurate, the data was still compelling. Ultimately the rendering engine is only one factor of resource usage, and other factors will be at play.

That being said I'm not concerned about bean-counting megabytes, as I'm not out to make a lightweight browser. I'll try to be efficient of course, but Fiber has some much steeper hills it must climb to maintain speed and resource usage for one reason; extensions. Extensions are inherently less efficient than native code, and many times when complaints Firefox or Chrome performance arise it can be traced back to misbehaving add-ons. With Chrome the browser separates extensions, plugins, and rendering engines into processes which is heavy - but stable. If Fiber did the same it would quickly become much heavier than Chrome as by design it will have multitudes more extensions.

Put simply if people start complaining when they have 3 or 4 inefficient extensions gumming up the works, imagine the moment of panic when you consider a browser that will ship with over a dozen default extensions for basic browsing!

Which brings me to the juicy performance stuff;

Simple by default; Fiber 'Performance Tuning'

You often see guides suggesting how to "tweak" Firefox or Chrome to be faster. Often they'll recommend isolating bad extensions and altering the basic behaviours of how the browser operates. Often though the defaults have been carefully considered… It's not like Firefox is shipping the "second best" configuration they can think of.

With that in mind computers are extremely diverse and for all intents and purposes no two computers are alike; OS, RAM, CPU, connection, physical location, and even drivers affect how well a computer can perform. For Fiber and it's extension-happy orientation performance can quickly become a nightmarish prospect; how can we guarantee that a browser with dozens of potentially unoptimised ECMA-driven plugins will perform well? And, if the user must intervene and "tweak" the system, how can we make this process simple and efficient?

The solution being implemented is to boil tweaking down to simple but powerful sliders the user can adjust: "Extension Processes" and "Loading & Fetching".

fibershotThese sliders are the first two added for performance tuning, and more may be added if they make sense. These sliders aren't completely voodoo though, and simply act as a front-end to the more fine-grain options hidden in the Configuration utility, and will adjust those values in a way that is safe and sane. "Simple by default, Powerful when needed".

Extension Processes

Though not anywhere near fleshed out, this had to be added early to ensure the concept would be propagated throughout the extension architecture. Extensions in Fiber will have a "separateProcess" variable in the manifest file which can hint how the browser should manipulate its process system. Depending on how the user has set the "Extension Processes" tuner, the two values together will affect how extensions will be processed in Fiber.

When set to "Fewer Processes" only extensions which specifically request process separation will be split from the main process. When set to "Most Processes" all extensions will be placed into separate processes regardless of setting. The middle-road option will favour process separation, but not force it.

The idea behind this is to let simple extensions like bookmarks managers be in the main browser, while more complex extensions like download utilities can safely ensure they won't poison the main process.The only catch-22 may be processes which embed more dynamic widgets onto the UI; I'll be trying to make stock widgets accommodating, but if embedding widgets onto the interface it may force an extension doing so onto the main thread. I don't know fully yet whether this will be the case.

Loading & Fetching

Loading and Fetching will affect how eager the browser is to load unopened tabs, and how willing it will be to forget inactive tabs. "Fewest Resources" will lazy-load everything, while being more eager to dump data. "Eager Loading" will actively load unopened tabs, and keep everything in memory.

Work Status

I took a break to nail down some VDG work, so progress had briefly slowed during that time to pencil-and-paper work. This was prompted by me merging some Fiber-related icons into Breeze, and then going on a binge where I frothed at the mouth and made 47 application icons. DON'T JUDGE ME. Now that I'm just waiting to make some adjustments to some straggling icons, Fiber development is back on full-tilt - at least the full-tilt that a full-time employee can give in his off-hours.

Much like Firefox, Fiber uses Sqlite for profile storage. Earlier today marked a milestone where Fiber is now creating empty profiles with config tables, loading them with data, and providing nice clean functions to reliably read that data. Profiles themselves have solidified quite a bit, and now the relationship between all the moving parts is much more clear.

Work is now going into making profiles able to validate and repair themselves, adding "isValid" checks before attempts are made to use a profile, and getting proper but meaningful alerts in for serious issues.

The profile manager has shaped up nicely, and expanded a little bit beyond my original scope. There's still a ways to go before the profile manager is 100% complete, but even to a relatively green Qt developer the quality of the toolkit has made things easy.

The Fiber icon has also been tweaked, and now has multilple resolutions which are pixel-perfect.

30 Jul 2015 4:38am GMT

29 Jul 2015

feedPlanet KDE

Busy is fun!

Bugs Bugs Bugs

The beginning of the day was reading some social media in the morning with breakfast catching up with the times. While going though my Google+ feed I saw a post that I seen before about the a bug with a krunner plugin. The plugin in question was this which Riddell, Dan and I debugged to find some more info about the bug such as that is effects Kubuntu, Arch and openSUSE so it is upstream related. Riddell provided some info on the bug page to maybe help resolve it later. All and all I learned some debugging stuff, compiling, grabbing source and some very tiny C++.


Then I was off to VDG again to work more on the High Contrast Color scheme for Plamsa 5 with Andrew Lake. The VDG started doing some concepts and design for a new secure login for KDE aka SDDM


For lunch we had the cafe in the University that we used yesterday again. For a starter I had Spanish Potato and Tuna Salad with a plate of Grilled Chicken and french fries. Ovidiu really really disliked his choice of squid.

AppStream/Muon and KDE Neon

After lunch Matthias Klumpp talked about his work with Debian/Fedora for AppSream with metadata to be used in Muon Discover as well as some redesigns for it to work better and look better for everyone. Up next was the long awaited KDE Neon where people from Kubuntu, Red Hat, and others

After Party

View post on imgur.com

Thanks to the GPUL we had an amazing party with actually good music, free food and beer/wine. There was dancing, swapping name badges and having fun in general.

View post on imgur.com

View post on imgur.com

This is a picture of us walking to the mall for the party:

View post on imgur.com

29 Jul 2015 12:17am GMT

28 Jul 2015

feedPlanet KDE

PSA: Plasma Mobile forums have moved

For a short while, the Plasma Mobile forums were hosted outside of the official KDE Forums. In our quest to put everything under KDE governance, we have now moved the Plasma Mobile forums under KDE's forums as well. Enjoy the new Plasma Mobile forums.

As a few users had already registered on the "old" forums, this means a smallish interruption as the threads could not be quickly moved to the new forums. We're sorry for that inconvenience and would like to ask everyone to move to the new forums.

Thanks for your patience and sorry again for the hassle involved with that.

28 Jul 2015 2:59pm GMT

Akademy A Coruña Photos

HJensSaturday lunch Lunch Time

Smart Tech and Sensible Tech

Jens describes Skittles and Doritos

Akademy team The wonderful organising team! Akademy Award winners

Elite Kubuntu developer Scarlett wins an Akademy Award! Developerymobil

Sebas shows off Plasma Mobile phone with a look that suggests he wants world domination by next year

akademy2015Group photo IMG_6485

hacking area

IMG_6450GCompris demos, ooh la la IMG_5992

The opening ceremony to remember absent friends

facebooktwittergoogle_pluslinkedinby feather

28 Jul 2015 10:48am GMT

27 Jul 2015

feedPlanet KDE

KWallet5 can be auto-unlocked during login again

I've just pushed a patch to KWallet5 allowing you to have your wallet unlocked automagically during login. This patch was originally done by Alex Fiestas for KWallet4, so all credits and free beers go to him; I've merely just forward-ported it.

You'll also require kde:kwallet-pam repo and pass "-DKWALLET5=1" to cmake. This will generate pam_kwallet5.so which then can be coinstalled with the same module for KWallet4 (plus it also enables some ifdef'd code inside the module). If you're still using some KDE4/Qt4 software which is using KWallet4, you will require both modules present.

How to set up kwallet-pam can be found over at Luca's blog (though he said he'll update it for KWallet5 later, so you may want to wait a bit :).

27 Jul 2015 12:16pm GMT

Plasma Mobile SDK

Where are the giants?

When approaching this issue I had been thinking about the issue for a while. I had mainly 2 problems: I was rather frustrated with previous Linux-based systems so far and the one I liked didn't really scale for us. One thing was clear: We had to stand on the shoulder of giants.

For the N9 approach, I would have had to concentrate on figuring out technologies that were long dead (and probably should remain). For the Android approach I found 2 big problems: We have to actually work on generating the actual binaries (which means, from any platform to a specific ubuntu-vivid-arm target) plus all the dependencies. This meant, creating a new distro, and we already had debian/ubuntu for that, let's use debootstrap! Oh, wait…

Old school

For a start, I took what sebas already started, in fact. Using debootstrap to create a chroot jail that could cross-compile the projects into our platform. This started to prove feasible really soon, as 2 or 3 days after working on it (and after fixing some issues that kept arising, mostly on KF5 itself and packaging), I already started to output binaries that could be deployed on the device.


New school

An idea I wanted to approach was docker. Everyone on the web world is shit-crazy about it and it's deeply based on traditional Linux, so there's quite in common already. Doing something similar to the deboostrap there was a piece of cake, and I managed to re-use the set up code I already had for the previous version.


Still, this second approach feels lighter and it's quite fun to investigate something new like that.


It seems that the jailed systems are the way to go, at least for now, so the tools I've created so far assume that they live in the jail as well. So, what do we have?

To be done

27 Jul 2015 8:27am GMT

26 Jul 2015

feedPlanet KDE

GSoC ’15 Post #5: Port Complete – Time for the Real Deal

With loads of help from people on #kde-devel, we finally managed to complete the KDE Network Filesharing port to KF5. Wasn't easy, given that this was my first time porting frameworks, but it was real fun. Apart from apol's blogpost shared in my last post, here's another post that was immensely helpful to me while porting: Porting a KControl Module to KF5. GoogleSummer_2015logo

kde-dev-scripts has a kf5 bit wherein there are perl scripts that would help in porting fast (did most of my work actually). When everything worked successfully, there was a linking error which wasn't getting fixed even after hours of googling. Turned out to be a moc header include issue, as pointed out by bshah on #kde-devel and fixing that, everything was a success.

Up next

I now need to replace kpackagekit that Samba currently uses with packagekit-qt, and this involves plugging in the code I wrote earlier into it. This would probably complete the Samba bit of my work.

This is turning out to be a great learning experience and KDE Code no longer seems alien to me. With almost a month to go, I am positive that I would be able to get good results.

26 Jul 2015 7:21pm GMT

Akademy Day 2

A beautiful morning in Spain!

The second day at Akademy started off with 10 or so hours of sleep!, which was much needed for basic functions (really happy I don't have to drive here). The hotel (Rialta) had great breakfast with coffee, OJ, bread with meat and cheeses, yogurt, cereal all the basics that makeup a great day!

To the talks!

First talk to start was with Lydia Pintscher with "Evolving KDE" which see went over what is planned in the next stage of Plasma 5 and what she wants to be planned as President of the e.V.

View post on imgur.com

Next up was Dan Leinir Turthra Jensen talked about the work going on with Plasma Mobile from porting to devices, running Android applications on it and more.

Kubuntu Team

View post on imgur.com

Harald and Rohan gave a talk about their CI(Continuous Interrogation) work.

Lunch and Group photo

View post on imgur.com

Then we had the awesome and big group photo with everyone currently at Akademy both the people who are going to it as well as the volunteers who help make the whole thing run. Shortly after the group photo was lunch which again was provided by the Schools cafe and paid for by Blue Systems, which was great with pasta, yogurt, fruits, and pudding!

Right after Lunch everyone was right back to hacking some Open Source goodness!

View post on imgur.com

Kubuntu Podcast reports in!

View post on imgur.com

After the Lunch was over Ovidiu-Florin and I did a interview with Matthias Kirschner for the Kubuntu Podcast which has a new episode coming out next month on August 5 with hopes of including this and future interviews from Akademy and if not the next episode.

26 Jul 2015 3:42pm GMT

Plasma Phone and KWin

As you are probably aware by now we announced the Plasma Phone project during Akademy this weekend. In this blog post I want to discuss the role of KWin in Plasma Phone.

Plasma Phone uses Wayland as the windowing system with KWin being the Wayland compositor. This is our first product which uses Wayland by default and also the first product which uses KWin as the Wayland compositor. The phone project pushed the Wayland efforts in Plasma a lot and is the only reason why we are able to make Wayland a technological preview with the upcoming Plasma 5.4 release.

The phone project gave KWin/Wayland into the hands of many developers who started to actively use it and to develop with it. This obviously helped to find lots of small and larger issues which then could be fixed. It triggered a stabilization process which reached a stage that I can use a Plasma Wayland session on my notebook with enough confidence that I won't lose data due to crashes. So thanks to the whole team for pushing the system to the limits.

An area which saw lots of work thanks to the Phone is the interaction between Plasma as the desktop shell and KWin as the Wayland compositor. With Wayland we keep the architecture of having a dedicated shell process which is not inside the compositor. This architecture has served us well in the past and we don't see a reason why we should change this. It means that KWin can serve as a compositor for other desktop projects, but it also means that Plasma can be used with other compositors. Now unlike X11, Wayland's protocols are secure by default. This means that Plasma as the desktop shell does not know anything about windows from other processes. To solve this problem we designed a special window management protocol which exports the required information. The protocols are still under development, but we hope that they can be also useful for other projects with a similar architecture (LXQt being an obvious candidate). Of course such protocols should only be used by the "blessed" desktop shell process - this is something we still need to implement and one of the reasons why at the moment Plasma/Wayland is only a technological preview.

Window management is not the only area where the shell process needs to be "blessed". Also for announcing information about its own windows, we need some more information. We need to know whether a window is a "panel" or the "desktop" view. So on the phone the shell background is just a desktop window, the panel on the bottom is just a normal dock. This allows us to share the general layering code with the X11 implementation of KWin. Even more having the panels marked as panels allows us to properly define the maximized area. And the windows on the phone open maximized by using the "Maximizing" placement strategy in KWin.

Working on the phone project also had some surprises. For example the virtual keyboard just didn't want to show. It turned out that the reason for this was that Qt(Wayland) only requests the virtual keyboard if it has keyboard focus. Keyboard focus inside KWin is bound to the "active" window. So we had to implement activating Wayland clients. But the initial implementation didn't really solve it, we still had areas where the keyboard didn't come up. E.g. on the desktop in the KRunner search field we couldn't get it to show. The reason was related to the described problem: we did not yet support activating Wayland clients when clicking on them. This got solved by implementing mouse action (and touch action) support inside KWin. So thanks to this change (done for the phone) we can properly switch between Wayland windows on the desktop with a mouse driven setup.

Another nice touch is that KWin requires a running Xwayland server. This gives us support for all "legacy" X11 applications such as Qt 4 or GTK2 on the phone. Just we hit a problem with them: they did not react on touch events. The reason for this is quite simple: touch support is not yet implemented in Xwayland. As a solution we implemented simulating pointer events in case a connected Wayland window does not bind the touch interface. Thus all Wayland and X11 applications can now be used with a touch screen - be it on the phone or on a notebook with a touch screen.

So far I have only spoken about progress made in KWin which is relevant for the desktop. So what about the phone specific adjustments? Well there are hardly any. In the core of KWin there is no phone specific code. The only phone specific code is the hwcomposer backend. This is a plugin used for creating an OpenGL context using libhybris and for reading input events (unfortunately libinput cannot read events on a libhybris enabled system). According to cloc this plugin is just about 800 lines of code and about 200 are just very straight forward mapping of Android key codes to "normal" Linux key codes. For comparison: KWin + kwayland/server currently have about 120,000 lines of code. And even this hwcomposer backend is not phone specific. It could also be used to run a normal KWin/Plasma session on any libhybris enabled device. There is one important difference of the plugin to the rest of KWin which is worth to mention: it is GPLv3+ licensed, while everything else is GPLv2+. The reason for this change is the fact that libhybris is Apache 2 licensed and this license requires a change to GPLv3.

26 Jul 2015 2:10pm GMT

Plasma Mobile Images by Kubuntu

Yesterday we revealed the project we've been working on for the last few months, Plasma Mobile and images of it on Kubuntu.

KDE has been trying for years to get Plasma working on different form factors with mixed success, so when I first started on this I was pretty intimidated. But we looked around for how to build this and it turns out there is software for it just lying around on the internet ready to be put together. Incredible.

It got very stressful when we couldn't get anything showing on the screen for a few weeks but the incredible Martin G got Wayland working with it in KWin, so now KDE has not just the first open mobile project but also one of the first systems running with Wayland.

And with Shashlik in the pipeline we are due to be able to run Android applications on it too giving us one of the largest application ecosystems out there.

The question is will there be traction from the community? You can join us in the normal Plasma ways, #plasma on Freenode and plasma-devel mailing list and #kubuntu-devel to chat about making images for other devices. I'm very excited to see what will happen in the next year.

Plasma Mobile announcement.


facebooktwittergoogle_pluslinkedinby feather

26 Jul 2015 2:00pm GMT

Licensing of KDE Code

Akademy, the yearly KDE conference is alive and kicking. During the last days we were discussing again about potential KDE licensing issues (for instance code that is licensed under GPLv2, but not GPLv3). That's why KDE is maintaining a relicense checker script, that every KDE contributor should enter herself/himself. I've blogged about it already in January 2015, but it cannot hurt to repeat it from time to time: From the KDE relicensing page:

A couple of KDE dependent projects or even libraries have moved or are going to move to GPLv3.

Unfortunately, GPL v3 is incompatible with GPL v2. This means that it is not possible to create a project linking GPL v2 and v3 code together. There is no problem for projects which are licensed GPLv2+ (version 2 or above).

A few parts of KDE are currently licensed as GPLv2 only. So far we have no reason to believe that this was something other than an oversight. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them.

Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file.

Short story: If you have not done so yet, please add yourself to the kde relicensecheck.pl file!

If you cannot add yourself right now, please consider sending a mail to kde-devel@kde.org publically stating that you're ok with relicensing all your contributions hosted on the KDE services under either GPLv23, LGPLv23, GPLv2+, LGPLv2+. Additionally, you can give the membership of the KDE e.V. the credentials to relicense your contributions in future (this makes a lot of sense if you cannot contribute to KDE anymore and are no longer around). Many of the KDE contributors did this already. Thanks! :-)

PS: The official way to give KDE the rights to change licenses would be by signing the KDE e.V.'s FLA. Please note, that the KDE e.V. will not abuse this by immediately changing licenses you chose. Instead, this mostly about emergency cases (think of someone who suddenly passes away). But the script mentioned above is already a good start, since we can use it to quickly scan our code and identify problematic parts.

Update: With signing the FLA, you give the KDE e.V. several rights:

It is important to note, thought, that signing the FLA also includes that the KDE e.V. gives you back all your rights, so for you and your contributions, nothing changes. There is a BOF session about all this on Monday, so make sure you attend if you're interested!

26 Jul 2015 12:57pm GMT

KDE Applications Versioning

A common problem for many applications contained in the KDE Applications releases are non-incremented version numbers. Often the maintainer forgets to update the version number of the application, like I did it for Kate since the first KF5 based release.

This means: On Bugzilla, I get bugreports that always tell me "Kate 5.0.0″, not very helpful.

KDE Frameworks solves this by automatic setting of the current framework release version in all framework CMakeLists.txt.

For KDE Applications, we have now optional the same concept. For details: visit https://community.kde.org/Applications/Versioning

In short: If you are to lazy to update your version number yourself or are just fine with using the same version number als the KDE Applications releases, you can add the following three lines to your toplevel CMakeLists.txt:

# KDE Application Version, managed by release script

These variables will then be patched by the release scripts to the "right" version for the current release series.
You can than either just use the MICRO version to suffix your own applications version to differentiate the bugfix releases or like Kate construct your complete version number from the three vars and be done ;=)

I hope this helps to have more consistent and more important meaningful version numbers once again in the applications we bundle. Thanks to all people that made this "magic" happen ;=)

26 Jul 2015 12:25pm GMT