From the land of wobbly windows
Me:
I’m sorry that $feature behaves differently to how you expect it. But it’s the way it is and that’s by design. The feature work exactly as it’s supposed to work. I’m sorry, this won’t be changed.
User:
With decisions like that, no wonder KDE is still a broken mess.
I wonder why the hell I even bother reporting issues. Bugs are by design these days.
Never again.
Have a nice life.
This week we have seen quite some bug fixes for 4.9.2 and the inclusion of the refactoring I blogged about in the beginning of the week. This of course still continues and more patches are in the pipeline. Also a few more effect configurations got ported over to KConfigXT.
Between writing about game performance benchmarks I also have to publish the report on the activity last week in KWin development.
The major issue this week has been an issue introduced in KWin 4.9.1. Under certain circumstances it was possible that KWin completely froze. From the perspective of a compositor that is the worst bug you can think of. I’m very sorry for introducing this issue and want to apology for any inconveniences.
Luckily the bug report hit us about release time and we were able to notify the packagers the same day and provide a fix for the issues the next day. In best case most distributions have never provided the faulty package to their users.
Apart from that as a reader of my blog you probably already know what happened this week. Some nice performance improvements hit 4.9.2 and 4.10.
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.
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.
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.
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.
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:
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.
This is the sixth blog post in my series bugs.kde.org for developers.
During software development it is quite normal that you have some dependencies between the bugs and features you want to implement. E.g. for feature foo you first have to implement feature bar. Bugzilla can help you track such dependencies in a nice way.
In most KDE projects I have seen poor man solutions to manage these problems. The most obvious one is to just write in one of the comments that first the other bug report needs to be implemented. But that’s a very bad solution. It can only be processed by humans by reading the comments and from bug report bar the reference is missing completely.
Another solution is to set bug foo to resolved later indicating that at some later state the bug will be fixed. But how likely is it that you remember to reopen that bug after you have implemented foo? I think it’s rather unlikely given the amount of bugs reported on bko that anyone is considering the resolved later bugs. I just checked that for KWin and of the 17 bugs resolved later many are fixed right now.
Another solution I have seen is to create a meta bug and set all depending bugs as duplicates of this one. We then find comments like “note: please check duplicates”. This is also a very bad solution as it requires to read through all the bug reports and it’s not what duplicates are for. It’s not the same issue after all.
All these solutions have one clear drawback: they cannot manage dependencies hierarchies. Consider the following hypothetical feature request: a user wants to be able to interact with a rotated window. This requires first generic support for rotated windows and support for input redirection. Input redirection makes only sense with Wayland. For this we need to add at least a build dependency in CMake, implement Wayland server and get rid of X. If we would want to we could split this up even further and we have a nice dependency tree like this one:
This is a graph rendered by bugzilla. So how does it work? It’s quite simple. Each bug report has two fields to manipulate the bug dependency: “Depends On” and “Blocks”. A bug which depends on another one can only be set to fixed after the other one is fixed. The same way a bug which is blocked cannot be fixed as long as the bug which is blocking is not fixed. In fact these two are exactly the same: if you add a depends on, the other bugs blocks field will be updated. So you can always navigate the tree from both sides.
Using the bug dependencies can really help you if you split up your work into multiple tasks. Combined with the searches you can get bugzilla telling you which bug you have to work on.