KWin a solution for non-KDE based Desktop Environments?

Recently I have seen more comments about using KWin as a stand-alone window manager in other desktop environments. It looks like quite some users are looking for a replacement for Compiz nowadays. But of course especially among the users of the lightweight desktops there is the perception that one cannot use KWin because it is done by KDE.

So I thought I spent some time on explaining about what it actually means. Of course KWin is the window manager of the KDE Plasma workspaces. And this means it is part of the KDE source code module called “kde-workspace”. Most distributions provide one package or a set of packages which depend on each other for this workspace module. This means to install KWin one has to install what people consider to be “KDE”. But it doesn’t mean that one has to run any other part of the kde-workspaces. KWin is a standalone application which only depends on the kde libraries and requires a few runtime modules (e.g. the globalshortcuts daemon or kcmshell4). One does not have to run the Plasma desktop shell or systemsettings or any other application provided by the KDE community.

So installing KWin requires to install a few more applications, but all they will do is take up some space on your hard disk. I know that people are sometimes very concerned about it, so I run “du -h” on my kde install directory. This includes not just the kde-workspace module with its dependencies, but more or less everything we have in KDE’s git repository including things like an office suite, IDE, webbrowser, artwork and many other things one doesn’t need to run a window manager 😉 The result of all that is just 13 GB of disk usage. Given current storage costs (0.06 EUR/GB) this costs less than 1 EUR which is less than a cup of coffee where I live. And remember KWin will need less storage. The bare kde-window-manager package in Debian is just around 10 MB.

I understand that people care about the dependencies and think this is important. I just don’t think it’s of any importance in a world where a movie needs significantly more data storage. Still we care about the dependencies and we are working on breaking down the dependency chain as part of the frameworks modularization efforts. One of the results of this is that we have documented dependencies nowadays. And we are working on getting the dependency to the Plasma framework as a runtime-only dependency over QtQuick, so that people can put together themeing for KWin which does not pull in any bits of the Plasma dependency. Help on that is appreciated 🙂

A more relevant issue is the question of memory usage due to running KWin. Unlike disk storage, memory storage is still rather constraint. Unfortunately it’s very difficult to provide correct measurements on the memory usage of a single KDE application. KDE applications have many shared libraries (e.g. Qt). So if KWin is the only Qt application, the relative memory usage is higher than when using several Qt applications as for example in LXDE on Qt.

Now a few highly non-scientific numbers: according to KSysGuard my self-compiled KWin (Qt4) uses around 40 MB of private memory and 38 MB of shared libraries (Qt, kdelibs, XLib, xcb, etc.). The memory usage also depends on what you use. If you activate the desktop cube effect with a 10 MB wallpaper put in the background, you will see this in the memory usage 😉 Just as another value for comparison: the iceweasel instance I’m writing this blog post in has a private memory usage of more than 700 MB. Of course KWin is with that in a different league than the minimalistic window managers, but one has to see that KWin provides more features and is a window manager and compositor. If one needs to run two applications to get close to the same feature set, it’s quite likely that the same amount of memory is needed. KWin has many features and there is no such thing as free-lunch in IT. It’s certainly possible to trim KWin down by not loading the KWin effects and ensuring that no scripts are loaded and simplified graphics.

Given that I can only recommend to give KWin a try and not to discard it because it is from KDE and might pull in some dependencies. Evaluate by the features we provide and you want to use and not by some random number on your hard disk or your memory usage.

In a Debian-based distribution, one can try running the installation command:

sudo apt-get install kde-window-manager

This an be safely run even if one doesn’t want to install KWin, because it will ask to confirm and one can safely abort the process. The interesting bit is that just above the confirmation message one will be able to read the amount of space which will be taken.

On my Ubuntu 12.04 (with Qt libraries already installed), this is:

Need to get 45.3 MB of archives.
After this operation, 134 MB of additional disk space will be used.
Do you want to continue [Y/n]? n

Note that apt-get will also install “recommended” packages, which are not essential to the functionality of KWin. You can disable them, and then the numbers go down a bit:

sudo apt-get install –no-install-recommends kde-window-manager
[…]
Need to get 41.1 MB of archives.
After this operation, 121 MB of additional disk space will be used.

here on Arch, a fancy kwin weights 18M, shared 36M.
Deps upon Xorg are ~400mb (a barebone Plasma session) , kde-workspace pulls in phonon, akonadi,samba,mysql and co. Not great for 3rd-parties.
Performance bursts with SC 4.10 and 4.11 on SandyBridge.
Fancy-Plasma users can improve productivity by simply setting animation speed to Fast and Glide in place of Fade in effects (disabling effect on app menus).

May I ask what is blocking adoption of a Plasma (and Oxygen:) themed QML Aurorae windeco by default in Plasma2? It would benefit other DE environments too (theming, footprint, ..).

“Given current storage costs (0.06 EUR/GB) this costs less than 1 EUR which is less than a cup of coffee where I live.”

A proper storage solution, aka SSD, costs between 0.75-1.5€/GB. I would not wish one of those faulty, slow, power hungry spinning ceramic platters upon my worst enemies.

If you have never used a SSD, do yourself a favor and grab one. It’s something every self-respecting developer should have. (What’s the point of a 3.5GHz 8-thread CPU if your storage solution can do <1MB/sec in random writes?)

Proper storage is relative. SSD is almost worthless. They might seem fast on a benchmark when it’s fresh, but actually try using one for real work that involves a non-trivial random write load. Slower than a traditional harddrive by far!

Reliability? HAHAHA I’ve seen so many SSD suddenly die it’s rediculous. I’ve seen a few suddenly loose a flash chip and basically end up with holes throughout the filesystem. Ive seen even more totalyl fail, just refuse to be recognized or return error for all reads at all LBAs.

If a harddrive gets a bad sector, you can still read off the rest of the data, very little loss. If a a bad head develops, that’s comparable to a bad flash chip in terms of waht the data looks like, but do a headswap and you can read off everything. If the controller goes out, just swap boards, all the data is on the platters, no magic tables to worry about loosing.

What do you do to recover a SSD? Nothing! Throw it in the trash. You can’t open a flash chip and change out a part to read the contents.

Most kwin dependencies are small. I don’t see the difference between a ton of small packages and one gigantic package. As for security, like most other packages, when a security issue pops up, they get patched. Just try to stay at the latest version.

On small or embedded systems you wouldn’t use compiz, neither would you use kwin, nor mutter, nor muffin. They require too much resources besides disk space.

KWin and it’s dependencies run as user process and are thus not really security relevant. Especially a window manager cannot expose security problems given that it’s running on X (which is a much nicer target to look at).

There’s also the “cost” of package upgrades. Installing those 13 GB *once* is not a problem, but you’re going to update/upgrade those packages again and again and again. Which does not only cost bandwidth, but also time.

I gave that number as an upper limit of all available KDE software for comparison reasons. People are claiming that it’s too large install size if one wants to use KWin. It’s to show that this isn’t valid today any more.

I do not understand your security concern. Software which is not started cannot expose security risks.