From the land of wobbly windows
On poular request I added a section on How to Build KWin to our Wiki. This aims to those who want to work on KWin but do not want to build all the dependencies and the other parts of the Plasma Workspaces.
I hope this can help some people to test and develop on KWin. In case you find any errors in the instructions, please let me know. I tested the instructions yesterday on my Pandaboard and it compiled KWin master against a dev environment of Ubuntu 12.04, so they seem to be correct 😉
From time to time it happens that I talk with fellow developers who tried to work on KWin. One of the common feedback is that it is difficult to find your way inside KWin, though most is in fact described in the Hacking guide. But when considering our largest class Workspace, I kind of understand why people find it difficult to work on KWin.
The implementation of this class starts with an interesting discussion put into a comment:
Rikkus: This class is too complex. It needs splitting further. It’s a nightmare to understand, especially with so few comments 🙁
Matthias: Feel free to ask me questions about it. Feel free to add comments. I dissagree that further splittings makes it easier. 2500 lines are not too much. It’s the task that is complex, not the code.
I do not know when this comment was added (git blame only allows going back till 2007), but I fully agree with Rikkus on this one, because today it’s not the complex task which is dominating and it’s also not 2500 lines but a little bit more. Also most likely I could not ask Matthias (Ettrich) anything about KWin anymore.
And we actually did something about it. Last year we had a Google Summer of Code project to identify areas which should not belong into Workspace and splitted those out. For example the handling of Screen Edges had been moved into an own class.
But one of the larger tasks which did not get merged during the project was to split out the Compositor from the Workspace class. So far the Workspace had been responsible for both Window Management and Compositing. But on closer look we realize that these are two orthogonal tasks with only very small overlap.
Recently I took up this work and rebased it on current master and started to extend the work. The compositing related code part has always been responsible for creating the Scene (the actual renderer) and the Effect system. The effect system is only initialized if the Scene could be created and when compositing gets stopped both are destroyed. So we have a clear connection between the Compositor and the Effects system and the Scene. Nevertheless both are implemented as a static pointer available to everything in KWin. But nothing outside the Compositor needs the Scene. In fact it was only used as a check whether Compositing is active.
As a result the Scene is now owned by the new introduced Compositor class and I’m working on making the Effects system also completely owned by the Compositor, though for the Effects the static pointer probably has to be kept around. Nevertheless inside KWin there is actually no need to access this pointer outside the Compositor.
But even after moving the Compositor from Workspace into an own class quite a few methods remained in Workspace for the D-Bus interface. When looking through the interface I realized that most of these calls were actually delegating to either the effects system or the compositor. So I decided to also split up this interface and export the effects system and the compositor as own objects to D-Bus. This has also the advantage that we do not offer to e.g. load an effect if the compositor is suspended.
Of course we cannot remove methods from our D-Bus interface as it is kind of our public API to the outside world and we don’t want to break 3rd party application or our own config modules. Given that the split is not sufficient to have less unrelated methods in Workspace. To solve this problem I introduced a very thin wrapper generated from the D-Bus Introspection XML. The implementation of this wrapper just delegates to either the Workspace, Compositor or Effects system. The result is that the Workspace is no longer directly exported to D-Bus and that the unrelated methods could be dropped – they were all unused inside the application. When leaving Qt 4 behind us we can then clean up the D-Bus interface and drop the unrelated methods and the wrapper.
The Compositor has not been the only area where I did some refactoring. Recently I added a new sub-menu to the Alt+F3 menu and was rather annoyed by the process. This menu is also part of Workspace and to implement an addition one has to add a private method, two private slot and two private members. Given the size of the class it’s lot of searching where to add the elements and the names are not the best. Basically one has to namespace the method and variable names to make them non confusing. To make the work even less pleasant the variable names vary in the naming: variable_name vs mVariableName. Personally I don’t mind the way how variables are written, just consistent please.
I was so annoyed working on this code that I decided to never again be annoyed about it and started to move it into an own class. Not only did Workspace get smaller by this change, but also the functionality of the menu is nicely coupled and I was able to rename the variables and methods to have sane and consistent names.
Overall the result of these three topics highlighted in this post are that the header file of Workspace dropped 120 lines of code which are about 10 % of the header’s size. And the two new introduced header both have more than twice the number of lines due to documentation being added to it. To be fair the menu already had documentation, but in Qt style on the implementation and not in the header. Most of our documentation is in the header so this also adds some more consistency.
This week we have mostly seen work on 4.10 and not so much on 4.9.1. Two further bugs in Window Switching got fixed and a few more bug fixes are in the pipeline (I have a small review backlog).
But the work on 4.10 is rather impressive and really important. First of all I want to thank Jammy Zhou for adapting our OpenGL test application to determine whether the Catalyst driver supports direct rendering with compositing. Thanks to that change KWin will default to direct rendering and OpenGL 2 on the latest Catalyst drivers (in fact KWin defaults to direct rendering on all drivers now). If you are already using a recent Catalyst version you can also set the environment variable “KWIN_DIRECT_GL” to “1” to enforce direct rendering, no matter what the test app thinks. This works with all currently supported KWin versions.
My work concentrated on finishing the Plastik port to QML which I just merged into master. The classic decoration is still around, I want to make sure that the QML port is working correctly first. Please give it a try with e.g. Project Neon.
Furthermore I did quite some refactoring. Last week I mentioned the addition of Screens to the “User actions Menu” and that actually triggered some working on that code as I realized that this needs to be split out. This refactoring got just merged, too. And last but not least, I finally finished some unmerged work from last year GSoC. We again and again broke the patch set which made it difficult to merge. The user actions menu which I merged first, caused serveral merge conflicts again, so that was not a trivial thing. I intend to do a dedicated blog post to explain the refactoring especially as I have some more work already prepared. The numbers of these three merged branches today are quite impressive:
21 files changed, 650 insertions(+), 353 deletions(-)
7 files changed, 812 insertions(+), 555 deletions(-)
36 files changed, 2509 insertions(+), 160 deletions(-)
This week we have seen many bugfixes for the next 4.9 release and more are in the pipeline. Overall nothing special happened, the distribution I wrote about last week fixed the downstream issue so we are no longer flooded by duplicate crash reports. Since the 4.9.0 release 39 bugs have been created against KWin and we already fixed ten of those. Most of the other bugs are of course duplicates and other incorrect states.
Next to bug fixing also some new features entered master aka 4.10. A patch to use mouse wheel in Cover and Flip Switch effect which had been blocked for some time by the feature freeze got merged and for the users of multi-screens we have a new nice feature: the window decoration context menu (alternative shortcut Alt+F3) gained a “Move To Screen” sub menu. When I worked on that code fragment I realized it needed to be refactored – that will most likely end up in the next report.
After the release of the KDE Plasma Workspaces 4.9 I have read quite often in the Internet that users and also Media assume that the next release will be 5.0. This is not the case, the next release of the KDE Plasma Workspaces, Applications and Plattform will be 4.10 to be expected at the beginning of 2013 (release schedule has not yet been finalized by the release team).
I do not know why people assume that there would be a 5.0 release but I guess it is related to the work on Qt 5 and KDE Frameworks 5. Also some people seem to assume that after 4.9 the 5.0 has to follow due to second number being single digit, but a simple look at e.g. GNOME would show that numbers can increase as long as one likes.
At the current time there are no plans yet for a 5.0 release of the KDE Plasma Workspaces and at least I do not see any reason to increment the first number even after the release of Framworks 5. I expect that there will at least also be a 4.11 release before we start to think about version numbering for software based on Frameworks 5.
Dieses Jahr möchte die KDE Community erneut einen Entwicklersprint im schweizerischen Randa durchführen. Diese Sprints sind besonders wichtig für die Entwickler. Der Sprint ist für den Zeitraum vom 21. bis 27. September geplant und es sind die folgenden Ziele für den Sprint gesetzt:
In der Vergangenheit gab es bereits einige wegweisende Sprints in Randa. So wurde letztes Jahr die Grundlage für Frameworks 5 gelegt. Genaue Details kann man auf dem Dot nachlesen.
Die KDE Community muss für diesen Sprint 35 Entwickler aus der ganzen Welt nach Randa bringen und dafür brauchen wir etwas Geld. Um den Sprint zu ermöglichen, wurde eine Spendenkampagne gestartet. Es wäre toll wenn möglichst viele an der Spendenkampagne teilnehmen würden.
Wenn du dauerhaft die KDE Community unterstützen möchtest, dann ist Join the Game genau das richtige für dich. Für nur 100 € im Jahr kannst du ein unterstützendes KDE-Mitglied werden (KDE e.V. ist ein gemeinnütziger Verein). Ich bin seit letztem Jahr nicht nur ein entwickelndes sondern auch unterstützendes KDE-Mitglied.
This week I present a summary for two weeks as I had unfortunatelly no possibility to write the summary last week. Of course the main event in this two weeks has been the release of 4.9.0 and as always this triggered quite a flow of new bug reports. Since the release on August 1st 38 bugs have been reported against KWin and an additional nine KWin related duplicate crash reports ended in systemsettings. What is really sad is that we have a duplicate rate of 47 % since the release. Many of the often reported bugs are easy to find and easy to trigger regressions compared to 4.8. This makes me really sad, not because we released with regression, but because such issues could have been spotted and fixed during the beta testing phase. My wish for 4.10 is that more users test the beta releases and report issues.
The most often reported bug since the release is unfortunately a crash in the window decorations configuration module. This is a very nasty bug and interestingly the reason for this crash is in my opinion just lack of communication. In 4.9 we changed the API of KDecorationUnstable, as the name says that is an Unstable API. We ensured that an incompatible decoration would not be loaded and does neither crash KWin nor the decoration module. Unfortunately we did not inform the distributions about the change. One distribution recognized that there is an ABI incompatible change and seems to have done what they use to do in such cases: change the ABI version of the package. The result was that also for the stable decorations the ABI changed. We were not prepared for such a case and did not expect incompatibilities in the stable API. The result is that the configuration module crashes in case a user has a 3rd party decoration installed which has not been compiled again with the new ABI. Overall the problem could have been easily prevented before by better communication. We should have informed the distributions and the distribution should have contacted us to clarify what to do.
Unfortunately a small bug entered 4.9: when using an Aurorae theme moving the window through the titlebar is delayed. It’s a bug we discovered a few days after the final tagging through the work on porting Plastik to QML.
Since the release we had quite a lot of bug reports for this issue and I have seen some forum threads about this issue. It is already fixed for 4.9.1 but this might be a little bit too late.
As the bug is just in the QML component, everybody is able to fix it localy. In order to do so follow these steps:
cd /tmp wget https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/9ee6a775d592ec3f105892c32c7576d6cdd7c210/diff/kwin/clients/aurorae/src/qml/aurorae.qml?format=diff cd /usr/share/kde4/apps/kwin/aurorae/ sudo patch -p6 -i /tmp/aurorae.qml\?format\=diff
And now restart kwin. Just use KRunner and type
kwin --replace
Please be aware that any distribution update for kwin will overwrite the local change and please note that depending on your distribution the path might be different (the path is taken from the Ubuntu package).
If you don’t want to experience such regressions in 4.10 I recommend to test the beta releases. The issue had been introduced in January or February and nobody had noticed (I use Aurorae but don’t move windows through the titlebar). I’m really surprised to see this issue being reported so often after the release that I have to write a blog post.
A small service announcment: as you might have noticed I did not write a this week in KWin post. I currently have a reduced connectivity which means the system having the xslt does not have Internet. So next week I will cover both weeks.