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.

Reply to “All the faces of Ubuntu”

Dear Mark Shuttleworth,

so you “have absolutely no doubt that Kwin will work just fine on top of Mir”. This is great and I totally appreciate that you think Mir is a great system. But I’m wondering why you don’t use KWin then, after all it will work fine on top of Mir and is Qt based?

But I have doubt that KWin will work just fine on top of Mir and I have already stated so. You might have wanted to check the facts before stating such claims (somehow I get a feeling for a pattern here).

What makes me think that you cannot make such bold claims:

  • You don’t even know how to write KWin
  • Currently the number of commits to KWin by an Canonical employee is 0 (git log — kwin | grep @canonical)
  • No Canonical employee has so far contacted the KWin team on how we could integrate Mir and whether we are interested at all
  • I have to question the abilities of Canonical to judge what other software can do and cannot after Canonical argued with non existing issues in Wayland for Mir
  • We are still waiting for the Wayland adjustments for KDE done by Canonical. May I remind you:
    We’ll help GNOME and KDE with the transition, there’s no reason for them not to be there on day one either.

I have to ask you to keep KWin out of the pro-Mir campaign. I didn’t ask for Mir, I don’t want Mir and reading blog posts like the one which triggered this reply does lower my motivation to ever have anything to do with Mir. Mir is an answer to a question nobody asked. It’s a solution to problem which does not exist.

Your community manager recently posted on Google+ he had a frustrating day. Guess what my week has been and guess who I can blame. Guess what I great day I will have after reading your blog post this morning.

War is Peace

Today I got many questions about KWin and Mir, how it affects us, what it means for our Wayland plans and so on. I did not want to write anything about it because I think there is nothing to write about, but before answering the same question again and again I think it’s better to put down a few lines here. Wiki will be updated once Wayland wiki is updated so that we have something to link to.

First question: Does Mir affect us? Yes, obviously. Because of Mir I have to write this blog post, Wayland developers have to get the FUD out of the Mir documentation, it’s creating tension and it harms the development. We will have to face again and again the question whether Wayland is better or not. So yes it affects us and I’m not happy about it.

Second question: Does it affect our plans for Wayland? I think it would be very unprofessional if we would change our plans just because Canonical did an announcement that they want to do an own display server for Unity (we didn’t throw away Plasma because of Unity either). Whether Mir provides technical advantages or not cannot be judged right now, we will have to wait and see, then we can make a decision whether it’s worth to change our plans. So far I have not seen anything in the documentation that would look like an advantage over Wayland. Given the incorrect statements about Wayland I’m very skeptical whether there can be any advantages. I don’t want to go into detail, just look on the Internet there’s already enough information about that. Also one should consider that Canonical changes plans for their distribution every other day. Just consider the number of toolkits which have been used for Unity – given that I would not bet on Mir will be used next year and that means of course that we should not consider it for our planning.

Third question: Will KWin support Mir? No! Mir is currently a one distribution only solution and any adjustments would be distro specific. We do not accept patches to support one downstream. If there are downstream specific patches they should be applied downstream. This means at the current time there is no way to add support and even if someone would implement support for KWin on Ubuntu I would veto the patches as we don’t accept distro-specific code. If Mir becomes available on more distributions one can consider the second question. Given the extreme success of Unity on non-Ubuntu distributions I’m positively optimistic that we will never have to do the evaluation of the second question.

This week in KWin (2013, week 9)

This week I can only present a very small summary. Somehow not much has happened, but the review list is getting longer. For users of Intel IvyBridge I would recommend to wait with upgrading to Mesa 9.1 till the release of KDE SC 4.10.1. One of our (optional) shaders seems to hit a performance regression on that driver. It’s not a really bad thing and we were quite lucky that we had a hot-fix for KWin on the day 4.10.1 got tagged. Thanks a lot to our users doing a git bisect on the mesa sources which allowed us to provide both commit and an example shader to the developers. This are the nice things about free software that make me really happy. Especially if you get in turn suggestions on how to improve the shader.

Summary

Crash Fixes

  • 315951: kwin crash when clicking kickoff widget (“K menu”)
    This change will be available in version 4.11
    Git Commit

Critical Bug Fixes

    Bug Fixes

    • 305434: Window shortcut containing space: “Launch Mail” doesn’t work
      This change will be available in version 4.11
      Git Commit

    New Features

      Tasks

      • 303313: Make KWin compile with C++11
        This change will be available in version 4.11

      This week in KWin (2013, week 8)

      Over the last week quite some bug fixes got merged into the 4.10 or master branch. We have some nice improvements for the desktop change OSD and even improvements for Multi-Head setups. The slideback effect operates on stacking order changes, now. This makes it working with Focus Follows Mouse.

      In the Qt 5 porting preparation quite some code got prepared, but not merged yet. Our paint-redirector which is responsible to bridge between window decorations and compositor got adjusted to no longer make use of the QPixmap/XPixmap relationship for xrender on raster graphics system. As a nice side effect of this work we will get some improvements also for the OpenGL compositor.

      Another area of work was the removal of QCursor usages in KWin. We used to use QCursor for setting a specific cursor when low level interacting with windows (e.g. setting the pointing hand cursor in Present Windows effect). With Qt 5 we do no longer get the underlying X cursor, so we needed to go for an own solution. We already used to have an own replacement for QCursor::pos(), which got now merged together with the other cursor handling code into an own class.

      Summary

      Crash Fixes

        Critical Bug Fixes

          Bug Fixes

          • 294490: ‘Slide back’ effect should react on stacking order changes
            This change will be available in version 4.11
            Git Commit
          • 314392: Position rule conflicts with maximization rule
            This change will be available in version 4.11
            Git Commit
          • 312728: “Show desktop layout indicators” option isn’t applied properly/immediately
            This change will be available in version 4.10.1
            Git Commit
          • 315114: KWin fails to initialize OpenGL ES on Mali-604T
            This change will be available in version 4.10.1
            Git Commit
          • 282677: Compositing not possible on each screen with multi head
            This change will be available in version 4.11
            Git Commit
          • 294865: Slide Back: Sometimes the Inactive window pops to the font for apprx. one frame when it is activated.
            This change will be available in version 4.11
            Git Commit

          New Features

          • 313379: Overlap factor of keepAbove windows in placeSmart should be infinite
            This change will be available in version 4.11
            Git Commit
          • 314402: String representation of KWin::Client should include caption, not name.
            This change will be available in version 4.11
            Git Commit

          Tasks

            This week in KWin (2013, week 7)

            This week we have seen much less new reported bugs than the week before. So the 4.10 release peak is over, but openSUSE and Kubuntu releases coming soon – history tells that will also results in lots of new bugs reported. This week a very interesting bug got fixed from the category “one wonders that has ever worked”. The symptoms were already really strange for the bug and if not a fellow developer would have reported it, I would not have believed it. And it took us quite some time to figure out how to reproduce the bug although I had the chance to work with the affected system at FOSDEM.

            The porting for Qt 5 did a huge step over the last week. KWin’s XRenderUtils library got ported from XLib to XCB and with that also “evil” usage of QPixmap got removed. Most of our XRender effects are now also ported to XCB. I hope to finish the QPixmap chapter this week.

            Summary

            Crash Fixes

              Critical Bug Fixes

                Bug Fixes

                • 314760: Keyboard input doesn’t work after assigning window shortcut
                  This change will be available in version 4.10.1
                  Git Commit
                • 313145: Edges and “hiden panels” stop working when System Activity is shown
                  This change will be available in version 4.10.1
                  Git Commit
                • 314756: (Desktop Effect) Mouse Click Animation does not recognize mouse buttons correctly
                  This change will be available in version 4.10.1
                  Git Commit
                • 314625: window border “stays on top” after using present windows
                  This change will be available in version 4.10.1
                  Git Commit
                • 314762: (Desktop Effect) Mouse Click Animation does not work when rising or focusing a window
                  This change will be available in version 4.10.1
                  Git Commit

                New Features

                  Tasks

                    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.

                    This week in KWin (2013, week 06)

                    This week we have seen the release of KDE Plasma Workspaces 4.10 and it looks like many people gave it a try over the weekend. My “bugs reported over last week” search gives me 41 reports – magnitudes more than what’s normal. My mailbox literally exploded this weekend. Not all of the bugs are new in 4.10, there are quite some which are actually older, so I don’t think we let some bugs through, but nevertheless: please test the betas. I prefer getting the bug reports before the final is released.

                    In the feature development department the most interesting events are the merge of the new screen edges implementation. Highlights are “multi screen aware”, glow known from Plasma’s auto-hiding panel being available on all screen edges when approaching with the mouse and no longer stealing screen edges (except corners) from active fullscreen windows. More things are planed like making it possible for Plasma to use KWin’s implementation (less code duplication) and only start the highlight if an action will be possible.

                    The second interesting new feature/bugfix is that KWin is able to detect whether the screen is locked and disables some privacy related effects. Currently all thumbnail effects get deactivated, screenshot and mouse mark.

                    Summary

                    Crash Fixes

                    • 314593: kwin crashes when applying “Invert” effect immediately after session unlock
                      This change will be available in version 4.10.1
                      Git Commit
                    • 314409: Moving to Other Workspace Crashed KWin
                      This change will be available in version 4.11
                      Git Commit
                    • 309695: Crash in KWin::Screenedge::unreserve on deactivating Actos script
                      This change will be available in version 4.11
                      Git Commit
                    • 313996: KScreen crashes KWin when switching between resolution options
                      Git Commit

                    Critical Bug Fixes

                      Bug Fixes

                      • 299901: Cube animation on border approach should not be used unless the electric borders are actually in use and the config should be disabled, align or hint the electric border configuration
                        This change will be available in version 4.11
                        Git Commit
                      • 255712: “Thumbnail Aside” effect visible when screen is locked — privacy issue
                        This change will be available in version 4.11
                        Git Commit
                      • 278137: Trailing artifacts when quickily moving windows and windowgeometry affect is enabled
                        This change will be available in version 4.10.1
                        Git Commit
                      • 314590: “Show Desktop” no longer works as a toggle
                      • 313826: Outdated “Moving/resizing” option pending in kwinrules
                        This change will be available in version 4.10.1
                        Git Commit

                      New Features

                      • 290887: Hot Screen Corners do not work properly in multiscreen setup with different resolutions
                        This change will be available in version 4.11
                        Git Commit
                      • 271607: Window Specific Settings for Disabling Screen Edges
                        This change will be available in version 4.11
                        Git Commit

                      Tasks

                        More rational approach to window decorations

                        This is a follow-up post to my client-side-decorations (CSD) on Wayland post. Personally I was positively surprised by the feedback in comments and on various media sites. Hardly any “you are an idiot” – for a controversial subject this is very positive.

                        There was one comment which motivated me to write another post on the topic:

                        I see strong arguments/feelings for both CSD and server side – can there by a hybrid approach?

                        This is exactly the point. Neither client side (CSD) nor server side decorations (SSD) are the holy grail. Both have advantages, both have disadvantages. Nobody is right here, nobody is wrong. If someone says he prefers CSD, he is right, if I say I prefer SSD, I am right. That’s quite important to get. In the end one has to evaluate the advantages and disadvantages and then decide which is the less evil.

                        For me this is server side decorations because of the disadvantages I pointed out for our workspaces. Others might decide differently and that’s just fine. I do not want to enforce SSD on anyone who prefers client side decorations.

                        In fact I would be fine with CSD if there would be an approach to make them work right. There have been many comments that it really doesn’t matter as it belongs in the toolkit and they will look the same. Yes of course, I agree that decorations belong into the toolkit and that they should adapt to the needs of the workspace they are running in. But I don’t believe the toolkit (except Qt) can do that. As long as there are so huge integration issues like getting an unfitting file dialog in the KDE workspaces, I just don’t trust that toolkits can do it. In that aspect there have been quite some comments, that the integration is already really bad, so it doesn’t matter if that part breaks as well. Let’s just say that I disagree here :-) I want to have more integration not less.

                        So in the end it has to be a hybrid approach. There are valid usecases for client side decorations even on a system enforcing server-side decorations (best example: Yakuake), but if the system does not want decorations (e.g. Plasma Active) the client’s should not draw an own decoration. And of course there is the Chromium use-case where the user should be allowed to decide.

                        All it needs is a small protocol allowing the server to negotiate with the clients whether CSD should be used or not (that would be useful on X11, too). This actually does not mean an overhead, because also for CSD there should be some negotiation between server and client to figure out things like button position, which buttons, colors, style and so on – which goes in the direction of CSD done right. Just saying: “it’s the Client’s responsibility” is causing the issues I’m afraid of.

                        Client Side Window Decorations and Wayland

                        This weekend I was at FOSDEM and attended a talk about Wayland for application developers. One thing that came around multiple times was that “applications have to provide the decorations”. Every time I had to cringe, because it’s just not true and I find it sad that people who give presentations about Wayland repeat that.

                        Nothing in the Wayland protocol requires Client Side Decorations or forbids Server Side Decorations. And that’s not surprising as it just should not matter to a protocol. The same is true for the X11 protocol, there is nothing said about window decorations. Just on X11 people realized that server side decorations are the better choice, but still there are applications doing client side (maybe people think that the possibility of re-parenting says anything about window decorations, it doesn’t you don’t need re-parenting to provide server side decorations). What is true is that the reference implementation of a Wayland compositor, Weston, requires Client Side Decorations, but it’s just one implementation and doesn’t say anything about other implementations. And here it’s important to remember that Weston is not Wayland.

                        There are good arguments pro and contra client side decorations. The most commonly listed ones pro client side are:

                        1. Only one texture needs to be rendered
                        2. No aliasing when rotating/wobbling windows
                        3. Application developers are free to experiment

                        The first two are true. I have to agree there. I know KWin’s OpenGL decoration rendering code and the problems with it. I do not like it and I do see the disadvantages. Also I do know that wobbling windows is not looking nice.

                        The third argument is more complex. Here I do not agree, because I have not seen any valid use cases for these “experiments”. All we have so far is the Chromium use case and since then nobody else came up with any use case. So somehow that shows that we are not restricting the application developers as some pro-CSD people would claim. In fact allowing CSD limits the possibilities of the workspace.

                        Plasma provides three workspaces: desktop, netbook and tablet. From KWin perspective the main difference is how window decorations are handled. On Desktop we have full decorations, on netbook we disable decorations for maximized windows (control moved to the Shell’s panel) and on active we don’t have any decorations at all. With client side decorations such possibilities are gone. We are no longer able to take the desktop further by just changing this aspect for all applications. Many KDE applications are useable on Plasma Active (tablet) without any adjustments. If they would use CSD they were not usable.

                        My main fear with CSD is that it ends up in a mess as we can see on Microsoft Windows. There CSD are common but applications don’t use it to do useful stuff, but to enforce their corporate design. This is bad for usability. Each application looking different? Stupid idea. Not even Microsoft is having a consistent decoration for their various products. Some have titles on the left, some centered. A complete mess. And my fear is that Linux would head there, too.

                        Is this fear valid? Well during said presentation Weston was running with two windows. They had different decorations. One was the terminal with minimize, maximize and close button on the right. One was a pdf viewer with a standard GNOME Shell decoration: minimize button missing. And during FOSDEM I had also a look on the decorations for Qt Wayland: again different decorations.

                        Now let’s take that further: an application for Unity will have the buttons on the left, a decoration for KDE will have two on the left and three on the right. Everything will look different, just on one system. Total mess and nothing I want to use (yes that would be a reason to switch to Mac if that would happen).

                        I had a talk with Andy from Qt Wayland fame about the CSD implementation and he explained me that inside Qt the CSD code gives some overhead and that they have a flag to turn them off. Which is great. And we in KWin already have server side decorations and will need to keep them around for legacy X applications. What’s the point then to use CSD in Qt if we already have the decorations and can give the application a better performance? Well none and that’s why I plan to use server side decoration in KWin on Wayland.

                        So if you read again somewhere that Wayland requires Client Side Decorations:

                        • Nothing in Wayland requires them
                        • QtWayland allows Clients to turn them off
                        • KWin as a Wayland compositor will use server side decorations

                        I do not want to go into the details of the contra arguments of Client Side Decorations as I have done that in the past. It’s a difficult topic as both pro and contra arguments are true. I personally see the contra arguments – especially the inconsistency – as much worse than the possible benefit of any possible pro argument. And please don’t come to my comments section and tell me that one can standardize on how the decorations should look like. If that were possible and feasible and would be used by application developers, we would not have already at least three different decoration implementations. It will end in the fancy I’m important mess from other systems.