Month: December 2012

One of our KWin Effects hasn’t seen much love over the last years and is in fact more broken than working. It’s a pure eye-candy effect which means that it is not at all in the development focus of the KWin team. The truth is, that we are tempted to just delete the effect because we won’t fix it. But of course there are users who like it and would be sad if it gets deleted.

Here you can help: if the issues gets fixed and the effect becomes maintained there is no need to remove it. So if you want to get your hands dirty with a small OpenGL based effect have a look at the Explosion effect and improve it. Have a look at Bug 312176 and all the linked reports to find the issues.

Due to vacations I was not able to work on any bugs and this also explains the lack of these summaries in the last weeks. Although we are in beta/rc testing phase it’s been not so many new bug reports, but still some work todo. Nevertheless we are already working on 4.11, that is mostly the port to XCB, which is not listed in the summary.

New Features

Tasks

The last three weeks I have been on vacations which explains the lack of blog posts. My batteries are fully recharged to work on KWin full time starting from January thanks to Blue Systems.

By pure chance I stayed close to the San Francisco Bay Area which allowed me to go to the Qt Developer Days in Santa Clara. It was great to see all the KDE and Qt people again and it was totally worth going there. I’m now looking forward to some great Qt technology coming up with Qt 5 (congrats to the release!) and I’m very very glad that ICS and KDAB organized the Dev Days and showed everyone that Qt has a bright future.

For me the conference was very valuable as I had the chance to discuss a few things about the next versions of our KDE workspaces with Aaron and David. And even if we do not yet have plans for a KDE workspaces release based on Qt 5 and KF 5 it became clear to me that my work for the 4.11 cycle will be mostly focused around the porting to Qt 5. This might sound surprising given that Qt promises 99 % source code compatibility. Well Lars Knoll mentioned that only platform dependent code needs to be adjusted and yeah: KWin is the 1 %. I will start to document lots of the tasks which need to be done in our wiki and will blog about it so that you can help with this task. A good example is that QPixmap is no longer bound to an X11 pixmap and well we used to do texture from pixmap from it (only with X11 PaintEngine in Qt).

Personally I do not mind much that we have to spend time porting to Qt 5. It gives us the opportunity to improve a few areas where we kept methods around for backwards compatibility in e.g. the D-Bus interfaces. Such methods are already marked as deprecated and some of them had been marked as “Should be removed with KDE 4”. It seems to me like the needed cleanup had been forgotten when we last had the chance. And that’s why I want to get done with the porting early. I would prefer having KWin run on top of Qt 5 as of 4.11 (of course that release will still be Qt 4 based) so that we can spend the 4.12 cycle to do lots of the cleanup.

One of the major areas for porting is the switch from XLib to XCB. As far as I have seen we would not be required to port everything to XCB, but overall it is a good idea to do so. It will make KWin faster and of course it’s better to have everything using XCB and using XLib only where – for legacy reasons – it is required: the GLX compositing backend (looks like our current EGL backend is also bound to XLib). Also the porting allows us to do some things “right”. Some KWin effects for example are interacting with X11 directly and that is something which should be tried to be abstracted properly so that we do not need to adjust the effects once we are running on Wayland.

Now that I mentioned the W word: you might wonder what happened to the plan to start working on Wayland from January. Well that has not changed much, it’s just that I learned more about the Qt Compositor which is a wonderful Qt-like abstraction on top of the Wayland C libraries. Nothing against the Wayland library, but it’s C. And I prefer working with a C++ Qt like API with CamelCase instead of underscores as so often common in C APIs due to lack of namespaces.

Internally we would have used a C++ abstraction anyways, because it’s just easier to work with it. With Qt Compositor we do not only get that for free but we also get a better API as the people at Qt have more experience in defining APIs than we do. And as another plus if we need something further we can just add it to Qt Compositor and share it with everyone. So all the code is set to greater usage.

The only “disadvantage” of Qt Compositor is that it absolutely requires Qt 5. So to be able to integrate it into KWin we need to first port to Qt 5. It is hardly any difference: we would have needed to go to Qt 5 anyway, when does not really matter, just that I now have a wonderful motivation to get there.

Over the last weeks the beta phase for 4.10 has started which means we have more bugs being reported and more bug fixes. Overall given the large amount of changes which might have broken (switch to KConfigXT, refactoring work in the compositor, xcb), it looks rather good.