Window decoration behind translucent windows

Yesterday evening just before the hard freeze a nice feature was added to KWin: window decoration painted behind translucent windows. Have a look:

Currently it’s supported by Aurorae, our only translucent decoration, and I think there are no applications yet which use the feature. But as it is proposed as an addition to EWMH I’m sure there will be in future. Somewhere I read that Mozilla Firefox wants to use translucent backgrounds. So that is your solution for the X11 platform.

Well this feature illustrates that we need a blur effect πŸ˜‰

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

47 Replies to “Window decoration behind translucent windows”

  1. Sorry, but I don’t get the point. Is it that the buttons, URL bar, … are opaque, while the border is not?

    1. The point is that the decoration is painted behind the window content. Normally we had decorations and window content and they never overlapped. Now the decoration can be painted behind the window.

      1. Real great stuff! And I really like Aurorae (for me, window themes should be SVG by default, as plasma’s).

        And how does it go under GTK apps?

      2. Is this happen in real time, so that we see whatΒ΄s changed during the movement in the background? Or just when the window stand still again?

  2. Wow! Fantastic!
    So, this will be supported by Aurorae, but what about Oxygen?
    Also, when do you think this feature will be supported in KDE apps (e.g. like Kontact)?

    1. Well Oxygen supports it, but it looks just the same as a normal window. It’s kind of useless because it’s not a translucent decoration.

      About KDE apps: not all apps should use this. E.g. all that have a menubar should never ever use this feature, because it will have a broken look. Candidates for such a feature are systemsettings and rekonq which just have a toolbar, but no menubar.

      1. With a transparent widget engine a good-looking opaque (or less transparent) background could be put behind just the elements that need to be readable, right?

  3. If I remember correctly the decoration in Vista is not quite as simple as painting behind the decoration: There is a slight built-in parallax so that the “behind” decoration moves when the window moves but not quite as fast as the window so that it appears to be not as far-away as the desktop.

    I’m not sure this makes sense physically but it does give the desktop a dynamic feeling.

  4. One thing I missed Hard Freeze to propose is making the whole window draggable, not just titlebar, as OS X and Windows do now. It not only would feel more natural to Oxygen (and derivated) and similar (those inwhich windows look to be a whole, not quite separated between titlebar and content) but would also certainly help regular users, who eventualy place windows in ways their titlebars get hidden and they get stuck by missing Alt+move feature.

    Would that be doable? (And sadly I’m not offering more than the suggestion, as I’m no kwin developer and C++’s still not one of my strongest abilities.)

      1. No, I think he/se means dragging with just a left click on any non-interactive portion of the window (that is, anything besides text areas, buttons, menus, or panels).

          1. No that is IMHO impossible. The window manager would need to know which areas of the window are non-interactive. The windows don’t tell the WM wich areas are non-interactive and even if how should it work. Just think about a browser: if you don’t hit the link it will move the window? Very bad.

            1. I don’t think that’s exactly how it works …

              Specially because a browser widget *is* interactive: even if you don’t do any web action (with link, forms or so), you can scroll it, select text and more. So move wouldn’t happen.

              It feels (I repeat, feels) more like the window is a whole piece (titlebar and window body have the same behaviour — includin window moving and context menu) and one of the two ways:

              * Either widgets pass ahead (to window) interactions with their “blank” spaces (like unused space — space with no entries — in menu bar or tabbars and some other spaces that do nothing) or;

              * Widgets don’t take more space than they show (that is, for example, menu bar don’t take the full window width — unless there’re enough menu entries for that — , only entries total width, and maybe tabbars don’t take more than existing tabs total width).

              I guess this is a longer discussion than your blog comments (I don’t wanna flood it) so where do you point me to suggest this, where KDE windows and widgets can be discused?

              And thanks a lot for your work and your time.

              Cheers

              1. Where to discuss it? Good question. I thought about it and I think it has to be handled inside the widget. That is if you drag in the widget, the widget will move the window without any help by the window manager. That’s a better solution than intercepting all mouse events and checking against an input mask. Still the question if it is at all a good idea that I cannot answer πŸ˜‰

          2. It should be possible as it works just like that in Chromium. The webkit-area isn’t a part of the non-interactive portion of the window.

          3. This is possible with Bespin widgets theme. It has an option to move windows by clicking in those empty areas. Look Bespin up on kde-look.org and try it yourself πŸ™‚

  5. Compliments Martin! You’re always making *great* stuff.
    I’ve got a couple of questions for you:

    – Is the background element painted only when the application switches to an ARGB visual? (so opaque windows won’t waste cpu)

    – Are there any caches for improving the performance, and do they affect the resizing performance?

    – Will it be possible to have a client-side API for switching on/off the blur? (the swithcing to/from ARGB is already possible). Are you planning other client-side stuff too? (like uploading pixmaps / embedding widgets inside the title, etc.)

    Apart from that: if you follow the instructions here http://labs.trolltech.com/blogs/2009/06/30/transparent-qwebview-or-qwebpage and browse to google.com, you’ll get a transparent browser as well πŸ˜‰

    Anyway: thanks, you rock πŸ˜‰

    1. Is the background element painted only when the application switches to an ARGB visual?

      It’s only painted if compositing is active and the window requests the feature. So nothing is wasted

      Are there any caches for improving the performance, and do they affect the resizing performance?

      In case of Aurorae the Plasma Pixmap cache is used. During resizing the svg is rendered several times. That is perhaps improvable.

      Will it be possible to have a client-side API for switching on/off the blur?

      Currently there is no blur, so no API πŸ˜‰ I thought of adding shortcuts to switching blur on/off for active window. I don’t think it’s something the app should control.

      Are you planning other client-side stuff too? (like uploading pixmaps / embedding widgets inside the title, etc.)

      No nothing in that way is planned.

    1. The translucent decoration is Aurorae. You can select it in Systemsettings -> Appearance -> Windows. The translucent window background has to be supported by the application, there is nothing you can turn on.

  6. Great stuff, KWin in KDE4 just keeps on pushing ahead.

    One question, though. You keep saying that the specific applications need to support it – isn’t this something that should be handled by the widget style in most cases?

    1. Only if the widget style is completely implemented to be translucent. So I guess in general it’s easier that the apps use this featur if it is useful. I don’t think that this featur is useful in general.

  7. Oh, and I missed it: sorry for not posting it under your answer but there was no link for that. But, still, I’m wainting for your answer about a place more appropriate, like discussion lists for kde windows and widgets, for this topic.

    Thanks again, in advance, for your attention.

  8. btw: I’d like to point out, that this behavior can also be activated in Bespin. And as mentioned before Windows, Mac OS X and even Chromium do this, so it can’t be a too disastrous thing

    1. Well if it is in Bespin it’s exactly what I said in another comment: it has to be handled in the widget or widget style.

    1. this has to be supported by both decorations and applications. AFAIK there are no applications supporting this feauture and Aurorae is the only decoration.

      1. In that case, where can I find the source to the demo above so that I can add the support to the application

        My deco is already aurorae

        1. I think there exists no code for that. The screenshot was made with a custom patch to a blurbehind demo from qt labs. I only tested the Aurorae integration part and made the screenshot. So sorry, that I can’t be a help

          1. Yes, that’s what I meant

            I compiled blurbehind, and that doesn’t have the deco behind either. What I would like is the source to this custom path that you mention so I can add the support to rekonq

  9. Thank you Martin for doing stuff like that!
    I really like that feature, it’s looking great! Strange, that I havend heard/seen anything about it so far (it’s almost a year now…).
    Sad, that features like that seem not to be used…

Comments are closed.