Category Archives: Help KWin

The relationship between Plasma and KWin in Workspaces 2

Posted on by
10

Yesterday during the Tokamak 6 sprint in Nuremberg we discussed the role of KWin in Plasma Workspaces 2. At the moment in Plasma Workspaces 1 KWin is of course the recommended window manager and compositor, but it’s also possible to use a different window manager. Back in the days there were quite a lot of users who run Plasma with Compiz. In theory that shouldn’t matter because everything is standardized with EWMH and ICCCM. Over the years we added more and more extensions to EWMH. It’s all open source so anyone can implement these extensions (Compiz used to do so), nevertheless right now there is probably no other window manager available to offer the full experience except KWin.

Plasma Workspaces 2 will be released at an interesting point of time. We don’t want to do the transition to Qt 5 and Wayland at the same time, so it will still be X based. But we all agree that our future will be on Wayland and even if we use X as the windowing system our primary focus is on Wayland. With Wayland quite a few things will change. KWin will play a more important role as it will be the Wayland compositor – we do not plan to use Weston.

Given that we know that the Wayland shell interface only covers part of what Plasma needs and some of our needs are extremely Plasma specific (for example Activities) it would be tempting to say that we tie KWin to Plasma. Let’s face it: which other compositor will be there to replace KWin? The reference compositor will probably never accept Plasma specific patches for things like Activities, Compiz won’t be ported to Wayland and GNOME Shell will probably never be a solution for Plasma. For the small window managers we do not know whether they will go to Wayland at all, but I expect rather not, though I expect that we will see Weston forks/extensions for substitutions of tiling window managers.

We decided to resist the temptation to go the easy road, but instead will develop all our integration bits in a way that one could replace KWin by a different Wayland compositor, even if that is just a theoretical option. Of course we will not do any fallback modes for the case that one is using e.g. Weston without Plasma integration bits. So the features which we need might then just be disabled. Adding fallback modes would most likely just result in bit rotting code as nobody would use it.

Of course to make it possible that others can provide compatibility features we need to properly document our extensions and additional interfaces. Luckily Wayland implicitly forces us to do so. The general plan is to publish our extensions and also try to standardize what makes sense to be standardized and we hope that this would also benefit other projects. What we especially had in mind is of course Razor-Qt which already supports using KWin. By properly documenting all our Plasma-KWin communication channel, they can also use what is useful to them and it ensures that we don’t break KWin in a way that it gets unusable for Razor-Qt.

[Help KWin] Create a KConfigXT file for KWin’s configuration

Posted on by

Just the other day a user in IRC complained about a default in KWin. I thought that the default he expected, is the one which is set in KWin sources. So I opened the respective source file and saw my assumption confirmed. But still the user claimed that there is a different default and I believed him. Further investigation showed that the source code of the configuration module had a different default set. It’s probably like that for years but it shows a problem: the config values are written and read at different places and the hard coded default values might diverge.

This reminded me of the great project we had last year to migrate the configuration of the KWin effects to KConfigXT and of the project to transform the configuration modules in KWin to have ui files. The combination of both calls for a new project: let’s migrate KWin core to KConfigXT. Now this isn’t a project which we will be able to do in one go. So I will split it into three parts:

  1. Create the kcfg file
  2. Migrate KWin core
  3. Migrate the configuration modules

Let’s start with the first one: create the kcfg file. Interestingly we already have such a file in the kwin directory – last change: Nov 20th 2007. It might be that some of the options are still encoded correctly, but I rather doubt it and default values are missing anyway. So I suggest to start clean. I would like to split the task into creating the XML part for the different config groups in KWin, so that the tasks are small. Later on we can then put it together to have one complete file. The project is outlined in this wiki page. Just add yourself to a section if you want to work on it :-)

[Help KWin] Save the Explosion Effect

Posted on by

One of our KWin Effects hasn’t seen much love over the last years and is in fact more broken than working. It’s a pure eye-candy effect which means that it is not at all in the development focus of the KWin team. The truth is, that we are tempted to just delete the effect because we won’t fix it. But of course there are users who like it and would be sad if it gets deleted.

Here you can help: if the issues gets fixed and the effect becomes maintained there is no need to remove it. So if you want to get your hands dirty with a small OpenGL based effect have a look at the Explosion effect and improve it. Have a look at Bug 312176 and all the linked reports to find the issues.

[Help KWin] Fix Warnings

Posted on by

Today I once more present some easy tasks to help the KWin development. This time it is a small coding task, though it’s not a very difficult task, but a very important one.

As you might know there is a new C++ standard available, which is called C++11. This standard provides quite some nice and useful additions to the language which we would like to use.

Unfortunately the new standard is not completely backwards compatible and there are some usages inside KWin which would no longer compile if we would enable C++11. This used to be totally valid code which did not even raise a warning. With gcc 4.7 we nowadays get a warning for all these code fragments which would not compile with C++11.

We need to fix those warnings, because we want to use C++11 in future and because they make it more difficult to spot the “real” warnings.

Therefore I set up a wiki page which contains all the warnings the compilation of KWin is currently causing and I would like to fix them all and that’s an easy way to help.

All you need is a current checkout of KWin and you need to be able to compile it with (at least) gcc 4.7. Please follow the instructions about building KWin. When you work on a warning just set the row in the table on the wiki page to InProgress and add yourself to the contact information. Please do this step as it prevents that multiple people start to work on it. Once you have a warning (or multiple) fixed, just open a review request on Review Board for group KWin.

If you work on it, please concentrate on warnings mentioning C++11.

[Help KWin] Update screen when Dim Inactive Effect Configuration Changes

Posted on by

Today I have a very easy coding task. In fact writing this blog post is more work than fixing it myself :-) I thought this is a wonderful task for anyone who wants to start contributing to KWin as a developer.

The task is documented in Bug 308283. If you want to work on it, just assign the bug to yourself, once you are finished either create a review request or upload a git format-patch to the bug report (git format-patch so that we can easily include it).

Please work on top of the KDE/4.9 branch as that should go into the next bug fix release and master and branch have diverged.

[Help KWin] Document Effect Animations

Posted on by

Given the success of the two community involvements I recently tried with KConfigXT and UI files (both merged into master), I decided to set up regular tasks and announce them through my blog. I will mark those in the caption with [Help KWin].

And this weeks task is a no coding task, but a documentation task. It is a task which can be considered as part of the Extra Mile project.

Let me introduce to the idea: some days ago I sent a mail to the kde-artist mailing list to get help on having better animations, because somehow it doesn’t feel as smooth as other compositors, but performance is not a problem. So our animations have to be wrong (I assumed) and I wanted help from people who understand it.

Well we figured out quite fast that the actual issue is that our animations are not consistent, e.g. two fade animations don’t look the same. Now that is actually pretty easy to fix and would give a much better user experience.

But before we can do so we need to know our animations and to be honest we do not know. So I call for help! Help us document all the animations going on. This would allow us afterwards to define basic patterns for the animations.

I just created a wiki page to document the progress and to explain how one can find the animations even if one is not familiar with C++. While programming skills can be helpful it’s not required for this task, it’s basically just “reading text” in the browser.