1

When compositing is enabled, I expect KDE to look better, but large portions of it remain an opague gray, which is something of an eyesore. I know I can make it another opaque color, but that is not the point. I would like these opaque regions to be translucent like the KLauncher and the Device Notifier.

According to people in IRC, including some of Kwin's developers, this is possible with hacks, but it will have poor performance because it is unsupported and that situation will not change until the people designing the themes require this functionality.

I think it would be better if KDE modified the Oxygen theme to make heavy usage of translucency such that the gray disappears when compositing is enabled. I also know that many Linux users who do not use KDE cite the opaque gray as being the reason that they do not use it. I think that making Oxygen a translucent theme when compositing is enabled would cause many of them to switch to KDE.

Someone is already developing a transparent version of oxygen, but problems with X11 makes it unreliable (for instance with video). The Bespin widget layer uses transparency, but it needs to blacklist particular programs because of these problems.

QtCurve also provides an option for transparency, but runs into the same X11 limitations as Bespin.

TheBlackCat wrote:Someone is already developing a transparent version of oxygen, but problems with X11 makes it unreliable (for instance with video). The Bespin widget layer uses transparency, but it needs to blacklist particular programs because of these problems.

I am talking about translucency, not transparency. The two are different concepts.

Would you care to describe the difference between translucency and transparency, or are you just being difficult?

No matter the word, we're talking about the same thing. Perhaps you should take a look at Bespin and QtCurve to see what we're talking about instead of assuming we're wrong and biting our heads off.

Renze wrote:Would you care to describe the difference between translucency and transparency, or are you just being difficult?

No matter the word, we're talking about the same thing. Perhaps you should take a look at Bespin and QtCurve to see what we're talking about instead of assuming we're wrong and biting our heads off.

Wikipedia describes it fairly well:

http://en.wikipedia.org/wiki/Transparen ... anslucency

People in IRC mentioned those. They have performance issues because it is unsupported in Kwin.

Ah, Wikipedia, the source of all true knowledge. *cough*

So your definition of 'translucency' includes diffusion, and you want blurring to occur behind the transparent (yes, I'm intentionally using that word) sections? Yes, Bespin and QtCurve can do that with Plasma's Blur effect, but not all parts under the window are blurred, and there are big performance issues. There always will be as long as we're still using X11. It is not just a kwin issue; it is a combination of kwin (or any other compositing window manager) and X11. So, to correct your statement above, it is because it is unsupported in X11.

X11 is rather old and dated, and its architecture for adding new functionality is limited at best. The only way we will get any 'real' compositing effects like this is to move away from X11 to a system that combines window painting and compositing in one. As I understand from some posts on planetkde, one possibility is Wayland. Only time will tell if this happens.

Renze wrote:Ah, Wikipedia, the source of all true knowledge. *cough*

So your definition of 'translucency' includes diffusion, and you want blurring to occur behind the transparent (yes, I'm intentionally using that word) sections? Yes, Bespin and QtCurve can do that with Plasma's Blur effect, but not all parts under the window are blurred, and there are big performance issues. There always will be as long as we're still using X11. It is not just a kwin issue; it is a combination of kwin (or any other compositing window manager) and X11. So, to correct your statement above, it is because it is unsupported in X11.

X11 is rather old and dated, and its architecture for adding new functionality is limited at best. The only way we will get any 'real' compositing effects like this is to move away from X11 to a system that combines window painting and compositing in one. As I understand from some posts on planetkde, one possibility is Wayland. Only time will tell if this happens.

Comments by Kwin's developers on IRC seemed to suggest that they could do it if the demand was there. i.e. KDE decided go go this route.

Shining Arcanine wrote:Comments by Kwin's developers on IRC seemed to suggest that they could do it if the demand was there. i.e. KDE decided go go this route.

I'm sure they could, but the performance issues would still be there because of X11 (do some research on how AIGLX works to find out more)... UNLESS the kwin developers bypassed X11's window functionality completely and painted windows the same way they paint plasma widgets. However, this would break any non-KDE aware apps rather badly.

I suspect the KWin developers "deciding to go this route" may involve switching to Wayland.

Then there is the problem of the shoddy state of Linux video drivers...