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
How you made this? I am great fan for fedora. I would like to know that are the things you have made so that its looking like semitransparent.
You mean the decoration? That is just an Aurorae theme/
Sorry, but I don’t get the point. Is it that the buttons, URL bar, … are opaque, while the border is not?
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.
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?
Depends – if the GTK app has transparency, it works. Not sure if GTK supports that
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?
yes in real time
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)?
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.
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?
[...] L’idea sembra simpatica ma per ulteriori informazioni a riguardo, consultare questo post. [...]
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.
Can I say I’m a fan of this one?
there’s in kde trunk?
yes
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.)
Are you talking about Alt+Left click+mouse_move on any window ?
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).
Yes, that’s exactly what I meant.
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.
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.
Hey guys.. the bespin window decoration can do this.
cya
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
It’s only painted if compositing is active and the window requests the feature. So nothing is wasted
In case of Aurorae the Plasma Pixmap cache is used. During resizing the svg is rendered several times. That is perhaps improvable.
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.
No nothing in that way is planned.
oh and I am not the one who implemented it. So your compliments should go to Fredrik
How can I turn it on?
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.
Excellent! these 2 features were already in bespin! great to have them in aurorae.
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?
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.
[...] [...]
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.
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
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.
[...] 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. [...]
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
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