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.

32 Replies to “KWin a solution for non-KDE based Desktop Environments?”

  1. PS: Your email news letter still shows wrong link to the new article. See in your inbox from 4.Nov
    BTW email Benachrichtigungen ueber neue Artikel auf dem Blog linken
    auf blog-admin.mgraesslin anstatt auf blog.mgraesslin.

  2. 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.

  3. For a less scary value than 13Gb, although with kde4 and with guestimated dependencies :

    kde-base/plasma-workspace-4.11.3: 444 files, 145 non-files, 10092.331 KB
    kde-base/kwin-4.11.3: 352 files, 143 non-files, 45595.954 KB
    kde-base/plasma-runtime-4.11.3: 150 files, 39 non-files, 3298.639 KB
    kde-base/kdelibs-4.11.3-r1: 3640 files, 253 non-files, 192327.263 KB
    kde-base/kglobalaccel-4.11.3: 4 files, 8 non-files, 149.41 KB
    kde-base/kcmshell-4.11.3: 2 files, 3 non-files, 55.625 KB
    dev-qt/qtscript-4.8.5: 77 files, 19 non-files, 19570.431 KB
    dev-qt/qtdeclarative-4.8.5: 266 files, 41 non-files, 32013.998 KB
    dev-qt/qtcore-4.8.5: 1568 files, 218 non-files, 66435.530 KB
    dev-qt/qtdbus-4.8.5: 78 files, 20 non-files, 3829.864 KB

    So you’re probably looking at less than 400Mb of disk space on top of plain X.

  4. I am using XFCE+KWIN with the Manajro spin Cutting Edge Linux

    The cube works great with nvidia legacy – butit did not work with the integrated ATI legacy – HD4250 –

  5. 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, ..).

    Hem.. can qt5 built-in window decorator serve almost OOTB other DE?

  6. “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?)

    1. It’s a bit less expensive (at least in France), sometimes you can find SSDs for 0.50€ to 0.65€/GB.

      Disk space is becoming a concern again for people who don’t want to use HDDs (like me)…

    2. When I saw that price, I knew there’sd be comments from SSD morons…

      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.

      Get a fucking clue!

  7. Dependancies are very important for safety concerned users: the more software you have installed, the more bugs you’ll probably have in you system than can be leveraged by malware.

    Disk space is of great importance in small and embedded systems.

    1. 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.

    2. 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).

  8. currently testing this out in virtualbox. is there any way to make kwin display shadows under menus/panels? or is that configured elsewhere?

    1. shadows need to be provided by the widget style. There are some (e.g. Oxygen) which make use of it.

  9. 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.

    1. But it isn’t 13 GB. That’s the max of all of KDE provided software, not just KWin. See the numbers in the comments to get a better value.

      1. Then why mention this number at all?

        Besides every unnecesary bit installed is an extra security risk that is just waiting to happen. Cost is not really the main factor, if it is not used it should not be there.

        1. 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.

  10. <> When you realy think, that dependencies are not important, why push the whole KDE Team so much Effort in it, please?

    1. Because there is a difference between the dependencies of a KDE application and making it easy for application developers to use our libraries.

  11. I remember you were discussing stripping down kwin (i guess its dependencies) with razor-qt team sometime ago. Is there an update on that front?

    1. one of the results of that is that there is the dependency documentation I linked in the blog post.

    1. just that it’s not KDE5, but just Plasma 2. We shouldn’t start getting into this “KDE5” thingy. KDE is a community and we don’t number people.

Comments are closed.