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.
Your link to the Qt Compositor is broken.
thanks. Fixed – I blame Firefox for hiding http://
In case you are annoyed by this behaviour: Type “about:config” in your address bar, look for “trim” and set/create the key “browser.urlbar.trimURLs” to “false”.
I’m looking forward to a better KDE as I tend to switch to it when GNOME2 in Ubuntu 10.04 runs out. Unity, Cinnamon, RazorQt etc. are too new, GNOME Shell doesn’t know where to go, Mate/Trinity are decaying, XFCE is going to port to GTK3 (I bet it needs time to stabilize it) and KDE has become stable on a sophisticated framework. I have no time for “gefrickel” 😉
When you copy the URL from the address bar in Firefox, it copies the http:// at the start, so you shouldn’t have any problems there. If it doesn’t copy, that’s definitely a bug and not an intententional feature.
well I used mark and middle click paste
Hi Martin,
Great blog! As for using Qt5 and depending on it. In my opinion KDE should depend on Qt5 asap. That makes it a lot easier (perhaps even attractive) to get rid of the (namely) “temporary” QML elements that where developed because Qt5 wasn’t there yet. + the very interesting oppertunity to use a much more powerful QML in KDE.
Perhaps KDE 4.12 can depend on Qt5.1? By the time KDE 4.12 is released Qt 5.2 is probably released as well since Qt is going on a 6 month release cycle as far as i know.
Cheers,
Mark
It pretty much depends on when KF 5 is ready, but I hope that 4.12 is a reasonable target for at least some early adopters. I don’t think that we can do in the workspaces all required XCB porting till 4.12.
Sam Spilsbury reflected a bit about Wayland and I think you should have at least read it:
http://smspillaz.wordpress.com/2012/12/24/sideways/
Thank you very much!
of course I have already read it and I disagree about the part on Weston. The same way as we currently have the need of multiple window managers there will be the need for multiple Wayland compositors. We can see this especially around the developments of GNOME that there is not the one approach to windowing systems to fit all.
But I also agree that we should share resources which is exactly the reason why I want to use QtCompositor instead of writing it for ourselves.
You need to think about how to reduce memory usage and prevent memory leaks in future versions of KDE, Kwin especially.
I do not understand what you want to tell me. If there is a memory leak, please report it and we will fix it. But at the moment we are not aware of any memory leaks.
Concerning memory usage I don’t think there is any need to try to reduce anything in KWin. For what we do we have a rather small foot print. So I don’t understand what you wanted to tell me with this post.