Month: March 2012

As mentioned yesterday I am currently going through all open feature requests for KWin. This of course tells me quite a lot about what our users want to see in KWin and where we have rough edges. Of course everything there has to be seen with some bias as some reports are really old and KWin has done a transition from being a window manager to a compositor and window manager. Given the age of KWin there has also been a dramatic shift in the targeted user audience of KWin and Linux in general.

One of the patterns I noticed in going through the requests is a high demand for our window specific rules framework. In fact I noticed so many requests for them, that I decided to create an own bug component for bugs and requests specific to the rules framework. This shows that the scripting capabilities currently added to KWin are useful and that there are many users who will appreciate that work.

Another area which has quite a rather large amount of wishes is Present Windows and Desktop Grid. This validates my assumption that it is one of the most powerful features we actually have for window management and that we have to make this more prominent. Personally I have quite some ideas to improve this in 4.10.

On the other hand there are hardly any requests for our other effects and if at all it is for accessibility features. When we introduced desktop effects there were many requests to add this effect and that effect, mostly with the reason that compiz has it, too. The more fancy, the better. Lately we have hardly got any new wishes for adding more eye candy. This quite validates some assumptions I already had. As desktop effects are quite normal nowadays on all systems there seems to be no need any more to have the show off effects. Who wants to burn down windows anymore? That was awesome back in 2005 as no other system could do something like that, but nowadays it looks already quite old fashioned.

Another area which really sticks out are advanced window management features like Focus Follows Mouse, Focus Under Mouse or Window Shading. Concepts probably not known to most users, concepts dating back to the early times of X11 and not really used by our current developers. If I think back to the developer sprints I have been over the last years I have not noticed anyone who used Window Shading.

Overall the feature request highlight something I expected before: feature requests are only reported by very advanced users. Only a very small sub group of our user base is able to report them. And that is no surprise. In most cases we can safely assume that a user of the KDE Plasma Workspaces does not know anything about KDE. Even if she does it is unlikely that she knows anything about KWin (try to find the word KWin in our UI). Even if the name KWin is known it is unlikely that a user knows that she could report a bug or feature request. KWin does not have a Help menu with a “Report Bug…” entry. So there is a huge entry barrier for reporting feature requests.

It shows again that bugzilla is hardly useful for interaction with the userbase as your userbase is not represented correctly. For KWin this will of course be fixed by no longer accepting feature requests in the bug tracker, but sending users to the brainstorm section.

As a reader of my blog you should know that I am rather unhappy with the situation of our bug tracker. Last week there was an incident with our bug tracker which should not have happened: the upgrade of our bugzilla installation broke the automatic submission of crash reports through DrKonqui. Given the stats for KWin of last year, I have to admit that I was not unhappy about it. My first expectation was that for at least a month we would not get any new crash reports and probably none for outdated versions ever again. Now our sysadmins and DrKonqui developers rock and have already fixed the issue 🙂

Nevertheless I took this incident as a motivating factor to start a cleanup of our bug tracker. Not getting new bugs and having to set them to duplicate frees some resources to go through the existing reports. At the time of this writing KWin went down 48 bugs and 160 feature requests over the last seven days.

During this work I concentrated on cleaning up the feature request. In the past the assumption was that each feature request is valid. Of course users may wish new features. Nothing wrong about that. Unfortunately this results in more than 350 feature requests and the oldest ones being reported against KDE 2.0. Well if a feature request has been reported more than ten years ago and nobody has thought about implementing it, we come to the point where we should consider facing the reality and stating that we won’t implement it. From the request I went through there were things which would have required a rewrite of KWin, many features which had been implemented or implemented in a slightly different way, just really bad ideas and many wishes for additions where we just don’t have the time for.

For the future I want to see new workflows established concerning feature request for KWin. First of all feature requests should not be entered in the bug tracker but on the brainstorm section of our forums. This allows other users to vote on the idea giving us developers a better understanding whether the feature is really wanted or just fixing a corner case of one user.

As a result feature requests in the bug tracker should only be there if we plan to implement them. For this I started to introduce “target milestones” for version 4.9 and 4.10 and started to flag the requests I consider as useful with these milestones. Feature requests which I consider as useful but cannot be implemented right now were made dependent on other feature requests which are already targeted for a specific release.

This will also change my own workflow for developing KWin. All the features I work on will end up as tasks in the bug tracker. Currently the ideas are either only in my head or as sticky notes on my whiteboard. Both is not a good solution for doing development planning and tracking dependencies between the tasks or verifying that all tasks get implemented before the feature freeze. But from my own experience I know that bugzilla is very capable of doing exactly that work.

For establishing such a workflow for myself it is of course necessary to first clean up the feature request. But in the end this gives everybody advantages. I have a better managed todo list which is shared with everyone. Given the target milestones all users and possible developers can see what (list is not yet complete) will end up in the release or where help is required.

Changing my own workflow is also quite important as I can manage my own available development time much better. Since November I have reduced my day job to have more time for KDE and started to do consulting work around KDE on the weekdays I have not been at my day job. Since recently I also belong to the group of developers working for the Netrunner OS distribution and since March the BlueSystems, the company behind Netrunner OS, is sponsoring two days a week for KDE development. Thanks a lot for the trust in the KDE community.

Now to something completely different: I not only worked hours through the bugtracker but have also been one day on a development sprint for Plasma Active. We had very good discussions about various aspects of the development of our workspaces 🙂 I used the short train journey to Darmstadt to rebase my JavaScript bindings for KWin Effects on current master with the result that yesterday I merged them into master. It still needs some final adjustments and documentation, but overall I’m quite happy about it. I remember that I talked about the ideas for the first time last year at the sprint before Plasma Active was announced and I think it is just a nice coincidence that I added the finishing touch to this work one year later on the way to and fro the Plasma Active sprint.

For our next release I want to improve the default options of KWin. For me it is very difficult to find good default options as I have adjusted KWin to fit my personal needs very well, so I need your help.

If you have ideas for better default options please post them in our Wiki on the Default Options page. Everybody can participate, all you need is a 4.8 installation of the KDE Plasma Workspaces.

You can also use the Wiki page to comment on some suggested changes and best is if you are able to open a review request for your change 🙂

Just as a small reminder: if you want to help the KWin development team you can also checkout our ideas.

Let me start this post with a big THANK YOU to our sysadmins and web designers for the awesome job on upgrading bugs.kde.org. The new design looks really great and the new bugzilla version brings some quite nice features. I really like the improved reports page and the HTML mails (although I normally never use HTML mails).

Currently a huge topic in the KWin channel is about providing help. Pablo has done a great job on documenting the Window Specific Rules. Luca from KDE Forum team asked me for a collection of things we could ask users to provide when providing support. I realized that this can be difficult, but that KWin itself knows everything which would help during support. So I added a d-bus and KWin Scripting call to print out support information.

qdbus org.kde.kwin /KWin supportInformation

or

print(workspace.supportInformation())

prints out a wonderful summary of the current state of KWin including used options, used compositing backend and relevant OpenGL driver capabilities. We plan to make this information even more accessible by adding it to our “useractions” menu.

For those who need help on writing KWin Scripts, I updated the KWin Scripting Tutorial to match the new API as used in 4.9. The example used in this tutorial got also updated in the kde-examples git repository. You will soon find there more examples: I intend to submit all the example code I write to test the API to this repository. The declarative scripting support has been merged into master and I intend to finalize the JavaScript bindings for KWin Effects this week.

But we do not only provide help, we also need more helping hands. And luckily we also get help. Just today I pushed a commit of a new contributor who refactored our inclusion checks for windows in the window switcher. Thanks a lot to Stefano for this great work.

Of course I have many more ideas for where KWin could be improved and I also have many ideas for small tasks a new KWin developer could solve (of course with mentoring), so I wrote them down in our community wiki. If you always wanted to contribute something to KWin, check out our Ideas and claim one for work. If you have any questions about one of the ideas feel free to contact us on IRC or mailing list.