Posted on

The relationship between Plasma and KWin in Workspaces 2

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.

Posted on

An update on KWin on 5

I realized I haven’t written a blog post to highlight the latest changes in KWin for quite some time. The reason for this is that we currently are mostly focused on getting KWin to work on Qt 5/KDE Frameworks 5. As I have mentioned already in the past KWin is a little bit special in the transition to Qt 5 as we used the low level native, non-portable functions provided by Qt (last week I found one usage of a native function which is not even documented). For us it mostly means that we transit from XLib to XCB and remove code which uses methods which got removed or replaced.

Although that means that we hardly have any new features there are quite some improvements all over KWin. Having to touch the code anyway allows us to also rethink how we tackle a problem.

For example we use Plasma functionality at a few places. The code got added before QtQuick existed so it uses QGraphicsView. With libplasma2 the QGraphicsView support is going to be removed which means we need to adjust our code. Over the last years some areas in KWin already made the transition from Plasma styled QGraphicsView to QtQuick, such as our Window Switcher or the Desktop Change OSD. But some areas remained: the close button in Present Windows and the add/remove desktop button in Desktop Grid. Here we have now a nice improvement ready for 4.11: these elements got rewritten in QML and they look way better now.

Aus KWin

For comparison just do Ctrl+F8 or Click here.

This was AFAIK the last bits of UI in KWin which hasn’t done the transition to QML yet. By using QML for all of our UIs the code becomes much easier to maintain, easier for users to improve it, easier to style it. The last point is really important for KWin adjustments for non-Plasma environments like Razor-Qt. Though they use a fair bit of Plasma styling already and with KF5 libplasma2 will be so small that it hardly matters 😉

The screenshot also shows another new improvement thanks to the transition to XCB. In the left upper corner a glow is shown when approaching the corner with the mouse cursor. If you use auto-hiding Plasma panels you already know this glow. This change became possible because the screen edge related code was one of our strongest user of XLib and a refactoring was needed anyway to support the world after X. The new design follows an approach which will make it easy to add support for a new windowing system – even if I do not know how exactly that will look like in a Wayland world (currently Qt5 is the highest priority). Also we plan to make KWin take care of the screen edges needed for the Plasma Panel. This removes quite some duplicated functionality from Plasma and solves the general “problem” that Plasma cannot listen to just all mouse events in a Wayland world.

One of the areas which has seen most adjustment so far is our XRender based compositor. It was a heavy user of the QPixmap/X pixmap relationship and needed to change. I still consider XRender as an important part of our compositing offering and therefore decided to do the porting. Interestingly the porting did also bring improvements to our OpenGL compositors. Again the reason is that we had to rethink. Our decoration rendering code used the QPixmap/X Pixmap relationship from the time when KWin only supported the native Qt graphicssystem. When we did the transition to raster the code did not get adjusted to the new world and that’s why we for example recommended the native graphicssystem for XRender. With the native system going away we just had to make it better and the improvements made for XRender benefit the OpenGL compositor in the same way. With Qt 5 I hope that we can get some further improvements for the QtQuick based window decorations. I was running KWin on XRender with raster and Plastik-QML as window decoration and was positively surprised: I couldn’t notice a difference in the speed compared to the OpenGL backend.

So how far are we with the transition to Qt 5? Last week I did a test compile against Qt 5 and KF 5. I hit a few issues but got it compiled. Apart from the known low-level issues (we still need some of the functions for Qt 4’s native graphicssystem) I only hit one compile issue with Qt 5 – given the source base that’s really a great job by the Trolls! In KF 5 I hit a few more issues – also because it’s not yet meant to be used. Well it doesn’t bother me much, I fixed the issues and started to integrate them either in KWin or in KF5.

But when it’s not yet supposed to be used, why am I investing time into it? The reason is the event filter. We need to transit our event filter from XLib to XCB and that’s something we can only test once we are running against Qt 5. I have some code prepared which at least compiles, though I know that it doesn’t cover everything and needs to be changed. I plan to give it a try over the next day, just to see how much breaks. But that’s the reason why we are doing it right now to have enough time till we do the final transition.

Posted on

Explore KWin’s Source Repository Change over Time

Today I’m happy to present some statistics about KWin’s source repository. The shown graph is HTML5/JavaScript, so I’m not sure whether that works on the planet or in an RSS reader. In case it does nto work you can get to the diagram here – as it’s an iframe it seems to be even bad on my blog. Best just open directly 🙂

What does this graph show?

For each (toplevel) directory in KWin’s source base the source line code is shown for each of our releases of the 4.x series.

How to use the graph?

The graph is interactive. With the checkboxes you can enable/disable the individual directories. With the drop down list you can select which information to show:

  • Total line count
  • Code and Comment
  • Code only
  • Blank only

The graph also provides context information. If you hover over a data point a tooltip is shown with information about the directory at the release. This includes the different counts and a break down per used programming language. The tooltip is not yet perfect and it might be needed that you disable a dataset to better read it.

What is 4.6*1 and 4.6*2?

Shortly after 4.6 got branched we did a coding style change over most of KWin’s source base. Due to that change we lost a few thousand lines of code. As that has not been any change in functionality the graph between 4.6 and 4.7 is incorrect. Therefore 4.6*1 is included as the commit prior to the coding style change and 4.6*2 as the commit of the coding style change.

Directories

main

With main the toplevel directory is meant. It contains the window manager and the compositor. Over time some features got split out into sub-directories. E.g. tabbox in 4.4, tiling in 4.8.

libs

In 4.7 the lib directory got split into two dedicated directories called libkdecoration and libkwineffects.

clients

For historical reasons the directory “clients” contains our window decorations such as Oxygen. Between 4.1 and 4.4 KWin contained the window decoration Oxygen twice. There was also a fork called Ozone with slightly different settings. Overall that meant that the code got duplicated. In 4.4 this situation was resolved by making another Oxygen fork called Nitrogen the new Oxygen. Also the theme engine Aurorae got introduced which explains the strong increase in size between 4.3 and 4.4. The strong drop in 4.6 is explained by moving some legacy decorations out of KWin.

kcmkwin

Kcmkwin contains all the config modules of KWin. Changes in source code are mostly related to new KCMs being introduced. 4.3 got a config module for screen edges, 4.4 a config module for Alt+Tab, etc. The only change in that pattern is that in 4.10 we introduced .ui files for our legacy KCMs which replaced C++ by more verbose XML code.

effects

Not much to say. I would recommend to have a look at this dataset without the other ones. One can clearly see how we got more effects till around 4.6 and then it started to stagnate. The strong drop between 4.8 and 4.9 is caused by moving some effects from C++ to JavaScript. The increase in 4.10 is caused by migrating settings to KConfigXT which introduced lots of XML.

tabbox

TabBox is the Alt+Tab implementation for switching between windows and desktops. It got split out with a new implementation in 4.4 and had been mostly untouched till 4.9 where large parts got rewritten in QML.

Scripting and Scripts

Scripting is KWin’s scripting engine for KWin Scripts and scripted KWin Effects. Scripts contains a few scripts we include to replace features from KWin core.

Tiling and tilinglayouts

The now removed tiling implementation.

data

Mostly KConfig update scripts

killer

The window killer (ctrl+esc)

What’s missing?

Unit tests

Unit tests are not considered as they tend to be rather large in code without adding any functionality.

Shaders

The tool to process the source base (more in the next section) is not able to parse glsl files. But it’s not much wc -l tells me 87 lines for the main directory containing the basic compositor shaders.

Plain Text Files

All the desktop files are missing. We have quite a lot but they are not really interesting as they are mostly containing translations.

Methodology

The data is generated using the tool cloc in version 1.56 as provided by the Debian (Wheezy) package cloc in package version 1.56-1.

For each of the versions (git tags) cloc was run in the git checkout (clean checkout just for getting the stats) once in each of the specified directories. The result was written into an xml file in a directory specifying the version.

For reference the shell script used to automate the process:

#!/bin/bash
KWIN_SRC=$1
VERSIONS=$2
SUBDIRS="clients data effects kcmkwin killer lib libkdecorations libkwineffects opengltest scripting scripts tabbox tools tiling tilinglayouts"

cd $KWIN_SRC
for i in `ls $VERSIONS`; do
  git checkout $i
  cloc --force-lang=XML,ui --force-lang=XML,kcfg --exclude-dir=clients,data,effects,kcmkwin,killer,lib,libkdecorations,libkwineffects,opengltest,scripting,scripts,tabbox,test,tools,tiling,tilinglayouts --xml --report-file=$VERSIONS/$i/main.xml .
  for j in $SUBDIRS; do
    cloc --force-lang=XML,ui --force-lang=XML,kcfg --xml --exclude-dir=test --report-file=$VERSIONS/$i/$j.xml $j
  done
done

This generated quite some xml files which were processed with a hand written tool. It reads in all the xml files, processes the information and prints out a javascript section to stdout which can be used as input for the jQuery flot graph library. Anything else in HTML and JavaScript can easily be seen by looking at the code 🙂 The order of the datasets got manually re-ordered to make more sense. E.g. having the three lib directories grouped together.

If there are more questions to the methodology: please ask and I will provide the information and in case something is missing extend the section.

Posted on

About network access, fuzzy specifications and non-POSIX calls with window managers

KWin supports a feature to recognize windows from a remote host. If KWin recognizes such a window it adds the host name (as provided by the property WM_LOCALE_NAME) to the caption. This is a very handy feature in case you work with remote system and use X11 network transparency. But it is also a feature hardly known or needed by most users.

Unfortunately this feature does not work properly for LibreOffice, because LibreOffice uses the FQDN instead of the hostname and KWin checked for the hostname. Some time ago the problem got fixed by using getdomainname to work around the LibreOffice situation. But this does not work in all cases and introduced issues with non-Linux systems as it is a non-POSIX call[1].

Of course one might ask why we don’t fix LibreOffice if only their usage of FQDN is causing a problem instead of fixing KWin. In this case it’s quite simple: LibreOffice is doing it right, everyone else is doing it wrong. Let me quote a section from the NETWM specification:

If _NET_WM_PID is set, the ICCCM-specified property WM_CLIENT_MACHINE MUST also be set. While the ICCCM only requests that WM_CLIENT_MACHINE is set “ to a string that forms the name of the machine running the client as seen from the machine running the server” conformance to this specification requires that WM_CLIENT_MACHINE be set to the fully-qualified domain name of the client’s host.

Of course the specification does not say anything about the case that the client’s host is the localhost. I would assume that the specification only considers the remote host case, but this is my personal interpretation based on the overall fuzziness of the specification. Given that it doesn’t say anything of the local system case, the interpretation of LibreOffice is absolutely correct by providing the FQDN. Also I can understand that one doesn’t want to maintain two code paths.

Now the fun part is that it looks like everyone else is not NETWM compliant in that point. In preparation for this blog post I forwarded an GTK+ based and a Qt (4) based application to another system and looked at the properties. _NET_WM_PID is set and WM_CLIENT_MACHINE contains the hostname, not the FQDN.

The fact that LibreOffice was always considered as a remote system had been unnoticed for quite some time. Personally I’m surprised by that and can only assume that users think that it was supposed to be called like that. I myself try to not use office applications and if I have to I use applications of the Calligra suite. But apparently it got noticed in the Trinity fork and a patch had been prepared there. After my last rant, the developer who wrote the patch, proposed it for inclusion on ReviewBoard. The patch used getaddrinfo to resolve the domain name for the provided client’s hostname. We decided against the patch because it is a blocking call to the network and in KWin we don’t do blocking calls. A blocking call in a window manager is pretty bad as it means that you can no longer interact with your windowing system in any way that would require a window manager. A blocking call in the compositor is deadly as the screen does not get updated any more. The system appears as being frozen. That’s why we have a clear no blocking call policy. This problem has been communicated to the Trinity developers and I suggested them to revert the patch [2].

I had put quite some thought into the problem and realized that it’s not going to be an easy fix and requires some internal rework to ensure that KWin can properly resolve whether a window is on the local machine even if it does not provide the hostname. Recently I sat down and turned my thoughts into working code. The general idea is to split out the complete hostname resolving into an own class to have this encapsulated. This class can provide whether the hostname it is encapsulating is on the local machine, so that we don’t have to query again and again – a problem I noticed when looking at the code: whenever the information was needed, it was queried again, which makes the interaction quite difficult if we are not allowed to do sync calls.

The resolving works as it used to be. So first the hostname comparison is used. If this does not work and the hostname looks like a FQDN then we do the resolving with getaddrinfo, but through a helper class and in a background thread. When the information is finally available a signal is emitted that it’s a local system allowing the external world to react on it to e.g. update the window’s caption. Interestingly when I worked on the code and started with the existing patch I noticed that it did not work correctly. Now a remote window with a FQDN was considered local if the name is resolvable. So overall we have now four approaches to get it right (initial code, first fix, Trinity fix and my fix) which shows that this is quite a non-trivial task and I wanted to be sure that it does not break ever again and if it does that we understand it. Therefore I wrote a unit test to cover the cases. I’m rather happy about that test as it is the first unit test I added which actually talks with X. So far I only wrote test code for non-X11 code.

Unfortunately there are now still cases where the information will be provide too late and a local system will be considered local. For example also the rule system and session management may need this information. Here not much is possible to be done. For window rules it does not really matter as by default we do not match the host at all and even if it’s more likely to try to match remote than local system. Also an adjustment of the rule to match a FQDN would work.

Overall this has been one of the most interesting bug fixes I had worked on recently which motivated this blog post. As this is a rather large change it is not going to be seen in 4.10, but only available in master (4.11). A decision made due to the long time the issue had not been noticed, which implies that it’s not a real issue for our users.

[1] This is a classic example for why I think it doesn’t make sense to state that we support non-Linux Unix systems. We break the code without noticing, because nobody is even trying to compile the code on non-Linux systems (also no CI system). The non-Linux system always have to catch up and fix our stuff and then they have a hard time to get the changes back upstream. This issue got reported to us with a patch attached. But I did not accept the patch as I spotted a possible issue and unfortunately there had not been any further trying on improving the patch. I couldn’t do it as I lacked the operating system to test it. Probably it was easier to carry the patch downstream than trying to get it into shape for upstream inclusion.

[2] That a commit entered Trinity which did not pass code review in KWin due to being dangerous is not surprising. This is no Trinity bashing, but it’s something to be expected when working on a foreign code base in an area that you don’t know. How should a Trinity developer know that you are not allowed to do blocking calls in a window manager? And even if you consider that as being obvious: how should a developer get the feeling to see a piece of code and ask himself instantly “is this blocking?”. This requires experience for working with a window manager and is something I explained to the Trinity developers in my very first mail to them where I suggested to drop their fork of KWin, because of exactly such reasons:

Working on a window manager and compositor comes with great responsibility. It is one of the most complex parts of the desktop environment and introduced bugs affect all users and can be really harmful and very difficult to debug. Developing a window manager is not trivial and you have to understand how the window manager works

And this is not a problem just for Trinity, it’s a problem for all such forks, be it Mate’s Metacity fork or Cinnamon’s Mutter fork “Muffin” or now Consort’s fork of whatever window manager they use at base (probably a GTK3 version of Metacity). I can only suggest to work together with the upstreams and unfork what can be unforked.

Posted on

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

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 🙂

Posted on

This week in KWin (2012, week 52 and 2013, week 1)

With Christmas break over there is again quite some work happening for KWin. Of course given that 4.10 is close by a few bugs got fixed, but with master open for 4.11 we also have the first feature commits. Most of it is in the area of porting KWin to XCB. Those changes are not listed, but they are quite nice as each of them brings a small improvement due to the asynchronous nature of XCB. For the actual features I try to create bug reports again, so that they can be listed in the summary.

Summary

Crash Fixes

  • 308040: KWin crashes after restarting it
    This change will be available in version 4.10
    Git Commit
  • 310142: KWin crash due to wobbly windows effect when closing window
    This change will be available in version 4.10
    Git Commit

Critical Bug Fixes

    Bug Fixes

    • 312346: PySolFC (And possibly other Tkinter and Tk programs), after moving window, put the menu at the original menu position.
      This change will be available in version 4.10
      Git Commit
    • 293385: glsl should be disabled for the 945G because it’s slow and broken
      This change will be available in version 4.10
      Git Commit
    • 308919: Window Switcher fails to repaint background if Fade Effect enabled
    • 311553: No minimum size on the general or effects tab of kwincompositing kcm
      This change will be available in version 4.10
      Git Commit

    New Features

    • 308992: Use Resize Area in Aurorae
      This change will be available in version 4.11
      Git Commit

    Tasks

      Posted on

      The road towards KWin on Qt 5

      The last three weeks I have been on vacations which explains the lack of blog posts. My batteries are fully recharged to work on KWin full time starting from January thanks to Blue Systems.

      By pure chance I stayed close to the San Francisco Bay Area which allowed me to go to the Qt Developer Days in Santa Clara. It was great to see all the KDE and Qt people again and it was totally worth going there. I’m now looking forward to some great Qt technology coming up with Qt 5 (congrats to the release!) and I’m very very glad that ICS and KDAB organized the Dev Days and showed everyone that Qt has a bright future.

      For me the conference was very valuable as I had the chance to discuss a few things about the next versions of our KDE workspaces with Aaron and David. And even if we do not yet have plans for a KDE workspaces release based on Qt 5 and KF 5 it became clear to me that my work for the 4.11 cycle will be mostly focused around the porting to Qt 5. This might sound surprising given that Qt promises 99 % source code compatibility. Well Lars Knoll mentioned that only platform dependent code needs to be adjusted and yeah: KWin is the 1 %. I will start to document lots of the tasks which need to be done in our wiki and will blog about it so that you can help with this task. A good example is that QPixmap is no longer bound to an X11 pixmap and well we used to do texture from pixmap from it (only with X11 PaintEngine in Qt).

      Personally I do not mind much that we have to spend time porting to Qt 5. It gives us the opportunity to improve a few areas where we kept methods around for backwards compatibility in e.g. the D-Bus interfaces. Such methods are already marked as deprecated and some of them had been marked as “Should be removed with KDE 4”. It seems to me like the needed cleanup had been forgotten when we last had the chance. And that’s why I want to get done with the porting early. I would prefer having KWin run on top of Qt 5 as of 4.11 (of course that release will still be Qt 4 based) so that we can spend the 4.12 cycle to do lots of the cleanup.

      One of the major areas for porting is the switch from XLib to XCB. As far as I have seen we would not be required to port everything to XCB, but overall it is a good idea to do so. It will make KWin faster and of course it’s better to have everything using XCB and using XLib only where – for legacy reasons – it is required: the GLX compositing backend (looks like our current EGL backend is also bound to XLib). Also the porting allows us to do some things “right”. Some KWin effects for example are interacting with X11 directly and that is something which should be tried to be abstracted properly so that we do not need to adjust the effects once we are running on Wayland.

      Now that I mentioned the W word: you might wonder what happened to the plan to start working on Wayland from January. Well that has not changed much, it’s just that I learned more about the Qt Compositor which is a wonderful Qt-like abstraction on top of the Wayland C libraries. Nothing against the Wayland library, but it’s C. And I prefer working with a C++ Qt like API with CamelCase instead of underscores as so often common in C APIs due to lack of namespaces.

      Internally we would have used a C++ abstraction anyways, because it’s just easier to work with it. With Qt Compositor we do not only get that for free but we also get a better API as the people at Qt have more experience in defining APIs than we do. And as another plus if we need something further we can just add it to Qt Compositor and share it with everyone. So all the code is set to greater usage.

      The only “disadvantage” of Qt Compositor is that it absolutely requires Qt 5. So to be able to integrate it into KWin we need to first port to Qt 5. It is hardly any difference: we would have needed to go to Qt 5 anyway, when does not really matter, just that I now have a wonderful motivation to get there.

      Posted on

      This week in KWin (week 46 to 48)

      Over the last weeks the beta phase for 4.10 has started which means we have more bugs being reported and more bug fixes. Overall given the large amount of changes which might have broken (switch to KConfigXT, refactoring work in the compositor, xcb), it looks rather good.

      Summary

      Crash Fixes

      Critical Bug Fixes

        Bug Fixes

        • 264041: “Switch to Screen” shortcuts are broken when using three or more monitors.
          Git Commit
        • 310646: No animations in the CoverSwitch effect
          This change will be available in version 4.10 Beta 2
          Git Commit
        • 309510: Logout Desaturation Desktop Effect no longer works correctly
        • 309170: If a windows is fullscreen the quick (un)maximizing is triggered when Alt+click moving it
          Git Commit
        • 276391: Desktop zoom shows wrong mousecursor while resizing window
          Git Commit
        • 309960: HTML in window titles not escaped in tabbox
          This change will be available in version 4.9.4
          Git Commit
        • 310613: Rendering of window decoration preview is broken/rendered white/partial
          This change will be available in version 4.10 Beta 2
          Git Commit
        • 309647: KWin uses incorrect function prototype for glXSwapInterval
          Git Commit
        • 309765: Closing a tabbed window gives focus to an other, but doesn’t raise that
          Git Commit
        • 310363: problem with extendedWindowBorders and dragAndDrop

        New Features

        • 307721: Make use of KDecorationDefines::ExtendedBorderRegion in shipped decorations
          Git Commit
        • 308994: Move ExtendedBorderRegion to stable API
          This change will be available in version 4.10
          Git Commit

        Tasks

          Posted on

          Fallback mode in KDE Plasma Workspaces

          Recently there has been a lot of buzz about non-composited fallback modes in various Desktop Shells and of course I have been asked several times about the fallback modes in KDE Plasma workspaces and whether they would be removed, too. Now instead of answering the same question again and again I decided to write a blog post to discuss the situation in more detail.

          The first thing to notice is that KDE Plasma workspaces do not have a non-composited fallback mode in the way GNOME Shell or Unity used to have. The main difference is that our window manager (KWin) is able to act as a non-composited, XRender based compositor and OpenGL (ES) based compositor. This means that we do not have to maintain two window managers in order to provide non-composited setups.

          The second major difference is that the Desktop Shell (either KDE Plasma Desktop, KDE Plasma Netbook or KDE Plasma Active) is not a plugin to the compositor but a separate application running in an own process. This allows to use a completely different window manager together with the Desktop Shell. Some years ago it was not that uncommon to use Compiz together with Plasma, though we see less and less such usage patterns (mostly caused by Compiz no longer being available in most major distributions except Ubuntu). This is a design decision which served us well and we do not plan to change it. Some time ago I brought up the topic, but more experienced developers (mainly Aaron) illustrated nicely the advantages of our design choices.

          Of course we need some code to be able to adapt to non-composited mode inside the Plasma workspaces. But this code would be needed anyway. Why? To answer this question we have to go back in time to when the development of Plasma had started – that is around 2006/2007. Back then OpenGL based compositing had been a rather new topic (I think I first heard about Compiz in 2004 or 2005) and it had only been possible with the binary blobs and hacks such as Xgl. The Intel hardware back then was not powerful enough and drivers were lacking, too. With other words: going an OpenGL-based only path seemed not feasible at that time and consider that the fallback modes in Unity and GNOME Shell got only removed in late 2012/early 2013. This is more than half a decade later – an eternity in IT. Also KWin did not enable compositing support by default till 4.2, so the first releases of KDE Plasma were non-composited by default.

          The solution inside Plasma was to make our themes aware of compositing. That is each theme contains an opaque element set which will be used when in non-composited mode. The fact whether compositing is used, is globally available through a standardized X11 manager selection. So whenever the compositing state is changed Plasma is notified and switches the used elements. Simple and elegant. This functionality served us quite well when we introduced the blur effect. Translucency is actually a very difficult topic. If you choose a too strong translucency level the text is no longer readable, if you choose a translucency fitted for text readability the translucency is hardly visible. The solution to this problem is the blur effect. It provides easily readable text even with strong translucency levels. But even today we do not enable the blur effect by default on all hardware as it is an expensive effect and we would not dare to enable it on embedded devices (personally I doubt that Windows 8 removed the blur because the designers disliked it). So we see we need themes with different levels of translucency depending on whether blur is available or not. The design decisions for the Plasma themes provided us the solution directly. As well it means that even if we would drop the non-composited mode we would have to keep our design to support the blur selection.

          For most of the applications it hardly matters whether the desktop is composited or not. Only very few applications use the alpha channel in the first place and if they want to use it, everything’s nicely abstracted inside Qt.

          Inside the window manager it also doesn’t really matter. Of course our window decorations are aware of whether compositing is used or not and especially Oxygen makes use of it by providing an adjusted look for the non-composited case, so there we have some overhead, but except that there are hardly any adjustments.

          This also means that we would not gain anything from requiring compositing. The compositor is a separate module inside the window manager which just gets started by the window manager on start-up. It lives more or less for itself and is just notified when a new window is added to the window manager and so on. Nothing inside the window manager really depends on the compositor. That means it would be more work to get KWin requiring compositing than to keep supporting the non-composited mode. And having the non-composited mode around allows us to do things like turning compositing off when running games or heavy OpenGL based applications such as Blender. So if you want to get some of the now finally available games for Linux, KDE Plasma should be your primary choice to enjoy the game. I have also heard of users switching to KDE Plasma because we still provide non OpenGL based setups.

          What remains is the question of what will change with Qt 5? Obviously not much. Plasma will continue to provide a non-composited and a composited theme, but Plasma itself will require OpenGL due to being based on QtQuick 2. I do hope that llvmpipe will be sufficient for Plasma in case of non available drivers. The same is true for KWin: our QtQuick based elements will require OpenGL 2, but that does not mean that we will require OpenGL based compositing. We will still provide non-composited mode and if the XRender based compositor get’s ported to XCB (we have lots of work there to get involved 😉 will continue to provide XRender based compositing as well as OpenGL 1 and OpenGL 2 based. Since the refactoring of the OpenGL based compositor I do not see much difficulties with keeping the OpenGL 1 based compositor around, though if it turns out to not be used anymore, it might be removed.

          The last remaining question is what will change with Wayland? Obviously Wayland requires to have a compositor, but it does not require us to stop supporting X11. KWin will continue to be an X11 based window manager allowing you to not use Wayland at all. And even if you choose to use a Wayland based KWin nothing says that it needs to be a compositor on top of OpenGL. Whether we will provide non-OpenGL based compositors for Wayland is a question for the future, though.

          A final remark: this blog post describes the situation inside the KDE Plasma workspaces and the design decisions we have done. This is not a critic at the design decisions other projects have done and I am not able to judge whether their decision is right or wrong and it is completely irrelevant what my opinion is on their decisions.

          Posted on

          What is a Desktop?

          A few days ago I started to work on a part of KWin which made me wonder what do we mean with the word “desktop” in the context of a window manager such as KWin. Of course in the sense of a window manager one means “Virtual Desktops” when speaking of “desktop”. Wikipedia says about virtual desktops:

          In computing, a virtual desktop is a term used with respect to user interfaces, usually within the WIMP paradigm, to describe ways in which the virtual space of a computer’s desktop environment is expanded beyond the physical limits of the screen’s real estate through the use of software.

          Inside KWin we identify the virtual desktop through mostly two properties in our Workspace class: currentDesktop and numberOfDesktops. In the X11 world the usage of virtual desktops is furthermore specified through the Extended Window Manager Hints (EWMH) which defines the root window property _NET_NUMBER_OF_DESKTOPS as:

          This property SHOULD be set and updated by the Window Manager to indicate the number of virtual desktops.

          And the root window property _NET_CURRENT_DESKTOP as:

          The index of the current desktop. This is always an integer between 0 and _NET_NUMBER_OF_DESKTOPS – 1. This MUST be set and updated by the Window Manager.

          As we can see the naming inside KWin is influenced by the specification which is implemented.

          Normally an X11 window manager implements the “virtual space” by putting windows on a virtual desktop. This is controlled in KWin inside the Toplevel class by having a property called desktop which directly reflects to the EWMH specification’s property _NET_WM_DESKTOP:

          Cardinal to determine the desktop the window is in (or wants to be) starting with 0 for the first desktop. A Client MAY choose not to set this property, in which case the Window Manager SHOULD place it as it wishes. 0xFFFFFFFF indicates that the window SHOULD appear on all desktops.

          The last aspect of the specification tells us that the desktop number “-1” is used to say that a window is on all desktops. Inside KWin we map that to a boolean property onAllDesktops.

          When looking at the source code of Toplevel related to desktops it is very easy to get confused due to the two following methods:

          bool isDesktop() const;
int desktop() const;

          So there is both a boolean and an integer property called “desktop”. That does not make any sense. How can a desktop be a boolean value? Looking at the Q_PROPERTY value helps us to resolve the confusion: the boolean property is there called “desktopWindow” which refers to a window type as provided by the EWMH specification:

          _NET_WM_WINDOW_TYPE_DESKTOP indicates a desktop feature. This can include a single window containing desktop icons with the same dimensions as the screen, allowing the desktop environment to have full control of the desktop, without the need for proxying root window clicks.

          In the KDE world that is our plasma-desktop application. A more modern name would be “shell” as we nowadays speak of Desktop Shells. Funnily enough a desktop window is normally not on any desktop.

          In order to get access to the desktop shell there should not be any windows in front of the desktop. To provide easy access there is the concept of “showing the desktop”. All windows are temporarily removed when entering that mode and restored afterward. Inside KWin this is controlled by the boolean property showingDesktop of the Workspace class which is again influenced by the EWMH property _NET_SHOWING_DESKTOP:

          Some Window Managers have a “showing the desktop” mode in which windows are hidden, and the desktop background is displayed and focused. If a Window Manager supports the _NET_SHOWING_DESKTOP hint, it MUST set it to a value of 1 when the Window Manager is in “showing the desktop” mode, and a value of zero if the Window Manager is not in this mode.

          Overall we see that inside KWin we have three completely different concepts denoted by the word “desktop”:

          1. Virtual Desktops
          2. A window which is the Desktop Shell
          3. Showing Desktop Shell Mode

          I can imagine that for developers having a look at the code for the first time this can be quite confusing. We see here a general problem in programming when one does not clearly define the concept in the naming. In this case the naming is fuzzy and can only be understood by someone with domain knowledge.

          Now how come I wrote this blog post? I started to further refactor Workspace and split out the handling of virtual desktops into a VirtualDesktopManager. This manager is supposed to take care of all aspects of virtual desktops like telling us how many there are and which is the current. While looking through the code I noticed how many methods there are with “desktop” in it which have nothing to do with virtual desktops. That made me wonder what else a desktop can be except a virtual desktop.

          It’s still quite some work till that code will be ready especially as I want to add unit tests to the new Manager but the improvements to the overall code base are already visible. The name makes clear that it is about Virtual Desktops and not about the Desktop Shell or the Showing Desktop mode and due to the class being just about Virtual Desktops the smurf-naming of all methods and properties could be removed. Much cleaner and easier to read. And of course the Workspace class is again losing a few hundred lines of code which is always a positive thing.