This Week in KWin (2012, week 30)

The major event of this week was of course the tagging of 4.9.0. We have two important fixes which made it into 4.9 and apart from that not much happened. My current work on Aurorae is not yet finished and has not been pushed yet. The work on it also discovered two small regressions in Aurorae 3 and I’m quite unhappy that we will ship 4.9 now with two known regressions. But they will of course be fixed for 4.9.1.

I want to use this rather quiet week to remember everybody about the importance of reporting issues early. We got today a bug report where the user mentions that he noticed this issue already with 4.7 and 4.8. Well by know it was already fixed in 4.9 and the user is unhappy that he does not benefit from the fix as he uses Debian Testing (which won’t go to 4.9 any time soon). If an issue gets reported when it got introduced more users will benefit from the fix and it’s much easier to fix the bug as it is more likely that we remember what we worked on.

Please report bugs only in English language. This week 2 of the 18 reported bugs were not in English. This makes it much more difficult to handle the bugs as there is a language barrier. For me even a bug report in German is completely useless. I use my software only in English and have problems with back translating the German translation to English.

Summary

Crash Fixes

304026: KCM crashes on updating a deco’s settings because the lib is conditionally unloaded in new ::canLoad()
This change will be available in version 4.9.0
Git Commit

Bug Fixes

303937: Quick tiling (snap) uses wrong geometry on alternate attempts.
This change will be available in version 4.9.0
Git Commit

New Features

Tasks

27. July 2012

QML Support for Window Decorations

Implementing a new window decoration for KWin is not the easiest thing to do. While the API has hardly changed since early 3.x releases it is not very Qt like and requires a strong understanding of how the window decoration in KWin works. To design a window decoration you basically have three options which come with KWin:

Subclass KDecoration
Subclass KCommonDecoration
Design an Aurorae theme

KDecoration gives a developer the most powerful options. The developer can design the decoration in whatever way he likes. But it also means that the developer has to take care about everything himself. E.g. properly laying out the buttons, handling mouse events on the decoration, ensuring the right resize handles are shown, etc. etc.

An easier way is to implement KCommonDecoration which already implements the common aspects of a decoration. For example a normal decoration has some buttons on the left and some buttons on the right side. The main task of a developer is to define how large various parts of the decoration should be, e.g. the margin between the left buttons and the caption. This of course limits the possibilities with the decoration.

The third option is to design an Aurorae theme which means just creating a few SVG elements. This is of course for designers the best option, but again very limiting. If a feature is not provided by the theme engine it cannot be represented. In the same way there are third party deKorator themes available.

The C++ based decoration APIs seem to be too difficult to be used. If we look at kde-look we see that there are just 14 native decorations available and some of them are forks or old versions of decorations available in KWin directly. But there are already 79 Aurorae themes available and more than 150 deKorator themes.

What seems to be a real issue concerning 3rd party usage can be validated if we just look into the KWin source base. In 4.9 we ship four window decorations: the Aurorae theme engine, Oxygen, Plastik, b2 and Laptop. Together they are 10 kSLOC of C++ code and 1 kSLOC QML code (Aurorae). Before Aurorae got ported to QML the size of the decorations was 13 kSLOC. Overall that is about 10 per cent of the KWin source base, which is rather large.

When I ported Aurorae to QML one of the nice results was that I had to add a QProperty based API to communicate with QML in the first place. If this were the actual API writing a window decoration would be probably much easier. As a first step in that direction I started adding generic QML support to Aurorae.

Following the general direction of all scriptable elements in KWin I decided to go for the well known Plasma Package structure, and added support to Aurorae to use a QML file from a package instead of the own QML file. The patch for this had been in my workspace for quite some time but I did not have any code to actually test whether it works.

So yesterday I started to re-implement one of our C++ based decorations in QML. I decided for Plastik as the decoration is in fact broken and had been scheduled for removal. We have not yet removed it as we acknowledge the user’s wish to have the KDE 3 look still around. But we are unhappy with having a decoration which is broken and unmaintained. So having a QML replacement would be something rather nice.

After one and a half days of work I’m proud to say that writing decorations in QML is possible. The changes to the configuration module and Aurorae itself are already under code review, the new Plastik still needs some love. But the decoration is already completely useable as can be seen in this screen shot:

In the current state the decoration consists of 370 lines of QML code and I expect to need an additional 100 lines to finish the buttons (they are already functional, that is the close button closes the window) and add some of the configuration options. The same API in C++ consists of 1500 lines of code. So we do not only get fewer lines of code but also a more readable and easier to maintain codebase. For something like a window decoration a declarative approach is much better suited than the imperative C++ way of painting elements.

Overall the new QML API will provide the same powerful features as the KDecoration API, but also provides convenience functionality as KCommonDecoration, e.g. a button group taking care of laying out the decoration buttons. To make development of QML based decorations quite simple support is currently being added to Plasmate as part of the Google Summer of Code project. So you will be able to design and also test the decoration directly from inside Plasmate. This is also quite some improvement as with C++ the only way to test a decoration is to use it in KWin, which can be quite nasty during development.

The API will need some more love till I’m quite confident to provide it’s usage but there is enough time till 4.10 🙂 So I hope that we can provide a better decoration experience in 4.10. I have a few ideas concerning the usage of QML based decorations in KWin and are looking forward to experiment with them.

22. July 201222. July 2012

This week in KWin (2012, week 29)

This week has not seen much development given that we are very close to the 4.9 final tagging. I pushed a little bit of refactoring into master (coming with unit tests), but apart from that we only had bug and crash fixes for 4.9.0 and even one regression in current master (4.10) got spotted and fixed. Thanks to Michael Pyne for bisecting and identifying the commit shortly after the commit had been pushed.

I’m personally very unhappy to see bug reports being opened for new issues in 4.9 even after RC 2 as it means that the previous beta versions have not been tested properly. None of the reported issues is a regression compared to the previous beta and rc releases, so they should have been spotted before. At this I also want to remind to report “obvious” bugs which you think someone had to have noticed. E.g. the fade effect incorrectly faded in a minimized window which got closed resulting in a flash with the window visible again. It’s a very obvious bug but might not be spotted by developers (e.g. I never close minimized windows). Interestingly this bug had been present since a long time but had been shadowed by another bug which got fixed in 4.9.

There has been one for me very interesting crash report which I cannot reproduce, but looking at the code the crash had been obvious and took me something like two minutes to fix. But as I don’t like pushing changes I cannot verify I wrote the first unit test which highlights an issue and verifies that the problem is fixed. In this case it was possible to write a test as the affected code is in the window switching framework which is seprated from KWin core and allows to mock the required objects. Nevertheless I had to introduce around 500 lines of mocking code to write a five lines test for a three lines change. Nevertheless it’s worth the effort as the next spotted bug in this area can be easily verified by a test.

What I’m very happy concerning the bug reports is that none of the bugs reported this week are still open. All reports have changed the state to either resolved or needsinfo. For a relaese candidate phase that’s pretty good, but still we are looking for people wanting to help with triaging the bugs.

Summary

Crash Fixes

303247: Crash after installed a new decoration
This change will be available in version 4.9.0
Git Commit
303713: kwin crash when adding applets into the main amarok window
This change will be available in version 4.9.0
Git Commit
303840: Kwin crash to do with hidden, empty or otherwise odd window titles
This change will be available in version 4.9.0
Git Commit

Bug Fixes

303397: KDE desktop effects are laggy when i uncheck Vsync option in system settings
This change will be available in version 4.9.0
Git Commit
303579: Rapid flickering in locked screen — makes it difficult to unlock
This change will be available in version 4.10
Git Commit
303891: Fade effect is being executed for minimized windows
This change will be available in version 4.9.0
Git Commit
303630: kde-workspace fails to compile, see kde-core-devel post in URL
This change will be available in version 4.9.0
Git Commit

New Features

Tasks

303314: Refactor Screen/Window PaintData
This change will be available in version 4.10
Git Commit
303093: Don’t use OpenGL matrix stack in OpenGL 2 backend
This change will be available in version 4.10
Git Commit

21. July 2012

Looking for KWin Bug Triagers

At the moment all incoming KWin bugs are managed by the developer community. This is actually not a really good solution as we have a high count of duplicate crash reports and also many bugs where we have to ask again and again for the same things (e.g. providing driver information or providing the list of loaded effects). Obviously if developers spend time on managing the bugs they cannot fix bugs in this time.

KWin is in the very lucky situation to have a cleaned up bugtracker. This means we don’t have old junk in the tracker and our bugs are nicely categorized by being put into the right categories. So becoming a triager would not mean cleaning up the old stuff but only help us with incoming bug reports. And that are in fact not that many – we get about 20 new bug reports per week.

For us developers it would be really helpful to only get the final and real bugreports. That is reports which have a way how to reproduce the issue and all needed information to properly investigate an issue.

So your task as a bug triager for KWin would include:

Finding Duplicate crash reports (very easy as DrKonqui adds the number of possible duplicates)
Identifying clear driver crashes (relatively easy if you understand a little bit about reading backtraces)
Escalating if a driver crash is reported too often, so that we can consider adding a workaround
Adding meta-information to the report: version, component, flags
Verify that the bug is reproducable
Add the steps to reproduce a bug if it is missing
Identify actual user support issues and send the user to forum.kde.org
Discard all Wishlist reports and send user to brainstorm.forum.kde.org

As we currently read all reports and are used to work with the bugtracker we can provide help and you can start by just watching our work in the bugtracker by following the shared bugzilla user. If you have questions about why we for example set a bug to duplicate I’m happy to explain that and for that I would prefer using #kde-bugs on freenode.net so that many bug triagers can get the information.

We would be glad to welcome you as a KWin Bug Triager and your help to make KWin a better window manager will be highly appreciated.If you are interested please leave a note, send a mail to kwin@kde.org or just ping me in #kde-bugs.

15. July 2012

This week in KWin (2012, week 28)

I decided to start a new blog category called “This week in KWin”. Based on the bug reports we resolved in a given week I am able to highlight important developments in KWin. This is not meant as a replacement or competition to the Commit Digest – I am very happy with the digest. But it is for overall KDE and does not give us any possibility to add further comments to it or highlight very technical things which might be noteworthy (yes, there is the digest tag for commits).

The biggest difference to the commit digest is that this report is generated from the bug tracker while Commit Digest is generated from git log. I think the bug tracker is a better source to track the development of a project as quite often you have a commit series for a specific bug or feature.

Important Changes in week 28

This week we have seen the tagging and release of the last release candidate for 4.9. As you can see in the summary below we have fixed quite a few issues last minute on Monday. This includes two rather important fixes for the rendering of thumbnails and the logout effect is finally available again. These were changes mostly done on last day of Akademy and while flying home.

We had received a very interesting crash report for 4.9 (4.8 is not affected) which got fixed (not available yet in RC2). When you use an Aurorae theme and close a glxgears window through the close button, KWin crashes. We had such issues with the old Aurorae implementation and had thought the port to QML had finally solved it. So we added the same and already known workaround from the old implementation to delay the closing by one event cycle.

Last but not least there is one important change for the 4.10 release. KWin’s window tiling capabilities which were implemented by a Season of KDE project a few years ago had to be removed again as the feature is seeing some bit rot and is completely unmaintained. Thanks to scripting it should be possible to implement window tiling again and provide it in time for 4.10. And work is going on to make that happen. If you want to help, please leave a note 🙂

This change does not affect the upcoming 4.9 release and does not affect the quick tiling on screenedges functionality.

Summary

Crash Fixes

179077: drag-and-drop between windows by cover switch alt-tab causes apps to crash
This change will be available in version 4.10
Git Commit
303450: kwin glxgears crash
This change will be available in version 4.9.0
Git Commit

Bug Fixes

296065: Lanczos Filter broken after screen size changes
This change will be available in version 4.9 RC 2
Git Commit
297864: ThumbnailItem allows upscaling of Windows
This change will be available in version 4.9 RC 2
Git Commit
302164: the efficiency of drawing in kwin 4.9 beta2 is lower than 4.8
303096: Logout effect completely broken
This change will be available in version 4.9 RC 2
Git Commit
303200: Incorrect signal connects for activities in WorkspaceWrapper
This change will be available in version 4.9 RC 2
Git Commit

New Features

Tasks

303090: Remove Tiling Support From KWin
This change will be available in version 4.10
Git Commit

14. July 2012

Do not use BleachBit

This week we received two crash reports after a user tried BleachBit. Reason enough to write a word of warning about this application.

BleachBit invalidates shared memory included our shared data cashes. Any KDE application using will crash once the memory got invalidated. As to my knowledge Oxygen is a heavy user of the shared data cache any GUI application is affected.

If you think that you need to use BleachBit I recommend to read the wonderful article on lwn about it: BleachBit: Does GNU/Linux need the equivalent of a Windows registry cleaner? If you don’t know what it is, just forget about it, but warn anyone who you will see using it.

8. July 2012

Akademy Impressions

Now that I am back home I finally find some time to blog about my impressions of Akademy this year. Overall it was a really great Akademy at an awesome location and wonderfully organized by the local team. Thanks a lot for your work!

For me it was the already the fifth Akademy – I hadn’t realize that before and was quite surprised, I still remember my first Akademy in Mechelen as it were yesterday. This year Akademy was a very special one as I had been a member of the jury for the Akademy Awards. I am very happy with the people and products we awarded this year. Camilla, Lydia, Kevin and Nicolás all do an awesome job in their area and all help shaping the future of KDE.

From a conference point of view my personal highlights were the talks about Qt 5 and Frameworks 5 (thanks to Thiago, Kevin and David) as well as Mirko’s talk and the talk about defensive publications. I’ll probably start to document some of the “innovations” inside KWin soon (personally I do not consider anything inside KWin being an innovation, but I see that we should have it published before someone gets a patent on what we did years ago).

My highlight of the days after the conference is the training on QtQuick 2 by our friends from KDAB. I was afraid that I would not learn anything new, but there was lots I did not know and I realized how I can improve my QML code quite a bit. Some of that (especially based on feedback from Nuno) already made it into the 4.9 release. But maybe most important is that I got an idea how QML based effects could look like which could contain shader elements as will be available in QtQuick 2.

While nothing is implemented yet I thought about how our Fade effect could look like in QML:

WindowEffect {
    id: myWindow
    opacity: 0.0
    onClosed: opacity = 0.0
    Component.onCompleted: myWindow.opacity = 1.0
    Behavior on opacity {
        NumberAnimation { duration: 150 }
    }
}

Well we will see how this idea will evolve.

Another highlight of the days after the conference was a session where Jeroen van Meeuwen was present and explained his plans for our bugtracker. I am very glad that there is someone who cares and wants to help us getting bugs.kde.org in a usable shape again. I am really looking forward to this happening and I hope that our developers will support his efforts and start using the bugtracker. I am convinced that bugzilla is our most important and most neglected piece of architecture and a proper usage will help us producing better products (and with that I don’t mean that we fix bugs).

Of course I hardly did any coding, but I mentored a BoF where I explained a little bit about the internals of KWin. I hope to see some patches and that is more important than me coding. But I fixed a few bugs I found by pure chance. And I must say this makes me rather unhappy. If a functionality is broken for almost a year and it’s me noticing then something is really broken. That I don’t use the functionality, that’s just fine. But that no user noticed that the logout effect has not been working at all in 4.8 is quite shocking.

So please my dear users: if you see some “obvious” bug where you think it must have already been reported, please report it nevertheless. Not each obvious bug might be obvious to the developers (I only suspend my system and over the last year got only logged-out by a freezing BLOB). I rather have a duplicate too many than a broken feature.

That reminds me: we currently have a release candidate out. Get it, test it!