Technical Limitations of Client-Side-Decorations

Sorry to blog again about Client-Side-Window-Decorations (CSD) but I was just made aware of the fact that you can open Alt+F3 in Plasma popups and that helped to produce this wonderful screenshot (sorry Eike and Plasma devs for destroying your apps in such a horrible way):

As we see all windows have KWin decorations and they should not have them. Yakuake has a kind of own CSD – you see the controls at the bottom. For Yakuake it’s totally fine to use the own controls as it has a very special usecase. Also all the Plasma windows should not have decorations as they are part of the workspace and by that not traditional windows.

So this is a technical and unsolvable problem for all windows which want to have CSD: the window manager may reparent the window and the window has no control over it. And this issue is really unsolvable, even if the NETWM specification would be extended it’s not solvable. There are window managers which have to reparent the window in order to function correctly. These are all tiling window managers. They have to be able to collapse the window into the decoration. Also KWin would never be able to support this correctly as we have features like window rules which can enforce a decoration for windows – no matter if the window wants or not. So to support it correctly we would have to break existing features which we don’t want (and KWin is a tiling wm, now). This also implies that we can never have a change to the specification as this would require consensus on all required parties and I think it is obvious that such a consensus does and cannot exist.

And just to show that this is also an issue for the only real existing CSD application out in the wild: I installed Chromium and it has two decorations:

This was the first time that I used Chromium. It opened up on Desktop 1, but I wanted to have it on Desktop 4 for the screenshot, so I rightclicked the Chromium decoration to move it to the different desktop and it doesn’t work. It doesn’t show the KWin useraction menu. Damn it, I was right, my concerns about CSD I blogged about in my last posts seem to be valid. There just is no consistency. Not to mention that it doesn’t have a menu button, no sticky button, the distance between maximize and close button is too small, clicking anywhere in the titlebar unmaximizes the window, the resize cursors are ugly and not the nice Oxygen one, the tooltips on the buttons have a different text to the one of KWin (no translation). Hmm kind of all my concerns from the last blog post are verified by this small example. When I wrote my last blog post I have never ever used Chromium. I only installed it once in a Lucid VM to illustrate the brokeness due to button layout. So all my concerns were not from looking at what doesn’t work in Chromium, but from what is clear to me what cannot work. So it was a pure theoretical post, while this is the experimental proof.

Please do not try to decorate Chromium with KWin decorations. It will most likely crash KWin!

I'm going to Akademy

=-=-=-=-=
Powered by Blogilo

17 Replies to “Technical Limitations of Client-Side-Decorations”

  1. You can actually tell Chromium itself to “use system title bar and boarders”: Go to options->personal stuff->appearance.

    However, all your points are still valid, and I really hate this myself — being a chromium user on KDE.

    1. Yes I’m totally aware that this is possible and it is completely irrelevant to this blog post 🙂

      But even if Chromium uses the systems decoration, it seems to have a tendency to crash kwin (at least our bug reports say so).

      1. I’m using Chromium + Kwin decorations from several weeks. So far so good. Before that, I was using Chromium native decorations and it was a pain. But I haven’t found that Chromium crashes Kwin…

        1. I got it crash kwin in less than one minute and we have quite some crash reports about it.

  2. I can’t get to bring out the kwin decorations in krunner or the plasma calendar.
    How did you do it?
    I press alt+f2 to make krunner appear, but then alt+f3 brings the kwin menu, not the decoration. Also, I can use the options there (move, resize) without seeing any decorations. I’m not using Oxygen decoration at the moment, I’ll try with it just in case.

  3. Of course, why didn’t I think of that? 😛
    Anyway, I thoght it was as simple (and therefore, bad) as calling the alt+f3 menu.
    Fortunately, making those decorations appear where they shouldn’t is something you have to reaaally want to do, not just by chance.

  4. Well, I think it is nice to have some kind control over the plasma, but bad side is that it is needed to do from KWin itself.

    Currently Plasma is broken in many places by it design. There are exactly problems like this clashing with KWin functions. (Others are with locking mechanism etc).

    But still the plasma has the very basic idea correctly done, it has same theme everywhere and possibility to tweak it littlebit. And in KDE SC 4.5 there is coming many great polishing (like the hided systray function).

    The Google Chrome is exactly one what does not look right at all. It has no problems if it is only application program what is running top of the OS (Google Chrome OS idea). But when it is among others, it looks ugly. And CSD is even against the basic functions of the X windowing system. We are not forced to have desktop environments, we can use only the window managers. And still we want all windows to work same way. CSD does not allow it.

  5. Actually it’s an intentional KWin feature that one can enable decorations on any window. It used to be blocked for borderless windows, but I did it on purpose when I saw that KRunner and Plasma windows don’t have decorations. I really hate it that e.g. the Plasma calendar doesn’t have window controls.

    1. Fair enough. But did you actually never ever right-click on a Plasma popup’s window decoration? At least under oS11.2+KFD+Qt4.7 KWin crashes…

  6. IMHO Yakuake, the KRunner and all the popup plasmoids are no different from Chromium. They should be under control of the window manager and get their decoration from it, too.
    In fact all the Plasmoids are ideally handled by the window manager, too. They remind very much to the subwindow-style MDI, which also sucks places both visually and behaviourially.

    In my dream world all containering and its management, be it of desktop panels or of stuff inside the classical window (menubar, toolbar, dock, tabbed subwindows etc.), would be done by the window manager. There is no need that every toolkit reinvents this stuff.

    1. IIRC it’s now possible to have the Plasmoids in own windows. For Plasma the behavior is realy discussable as both positions are valid: you can say they should behave like windows and that it is part of the workspace and by that no traditional windows.

    2. Plasmoids are not windows. The typical mistake what people believe is that widgets/applets/gadgets or plasmoids are like windows so you need to do same things with them.

      It is true that windowmanager is the technology what draws them, but there is other point as well than the they are not windows. They are all themes with same theme. They function same way. They are together.

      The workspace is different than desktop environment. The workscape does not include application programs (AFIU) but only the desktop, panels (all plasmoids) and then widgets.

      It is better when application programs starts being for single tasks. One for word processing, one for photo editing etc. They are windows in the screen. And workspace is just the like the table and shelfs in the kitchen, you need them, but you do not directly use them.

      1. If they should behave differently than windows, as you explained, kwin should not apply desktop effects to the widgets and their popups. I shouldn’t be allowed to alt-right-click-resize them and alt-left-click-move them.

        I think its the way to go, but the implementation should stick with your goals.

    3. I agree. IMHO, Plasma should work like any other app, using standard windows, plain Qt widgets and widget styles (even if they’re reparented onto a QGraphicsView, that’s what widgets on canvas are for) and as few of those custom SVGs as possible (and there should be a way to theme Plasma using C++ code, as SVGs can never be as flexible as C++ code).

  7. The freedom of choice for user interface is one of things I like in Windows. You don’t have to stick to some particular (and often boring and limited) view of UI that platform creators had. You are not forced to redesign your cross-platform app just to suit particular UI theme.

    How come that “free” desktop environment is less free?

    I wish all the applications just opened their own screens, like we had in Amiga times.

    1. I do not understand how you can compare that to Freedom. You are totally free to do whatever you want (as well as saying whatever you want). But we are also free to ignore what you implement (as well as everybody is free to not listen to what you say). So sorry that’s a pretty bad argumentation and doesn’t work with me

Comments are closed.