Red Hat Bugzilla – Bug 981665
transparency of gdesklet erratic in KDE
Last modified: 2013-07-09 16:39:31 EDT
Description of problem:
I'm using the gdesklet GoodWeather desklet, since it's the weather
applet with most information in a compact format.
Under XFCE4, the desklet is transparent as it should be, and I never
had a problem with that.
Now I'm trying to switch to KDE, and the desklet works, but its
transparency is broken in a weird way:
- After login, the desklet starts, but it's not transparent but rather
on a black background. Moving or restarting the desklet doesn't change
- The desklet can be made transparent again, by opening KDE System Settings,
-> Desktop Effects -> Advanced -> Change the "Compositing Type" from
OpenGL to Xrender *or* vice versa!
It does *not* matter, what the original compositing type was, OpenGL or
XRender, the desklet invariably starts with black background, and it does
*not* matter which compositing type is switched to, the desklet goes
invariably transparent after switching the compositing type.
After switching the compositing type, the desklet *stays* transparent, even
when moving or restarting it, and even when stopping the gdesklets daemon
and starting it anew.
Again, this only occurs in the KDE environment, under XFCE4 transparency
of the desklet always works fine.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start KDE
2. Start gdesklets
3. Start the GoodWeather desklet.
5. Login to KDE again
6. Observer the GoodWeather desklet having black background.
7. System Settings -> Desktop Effects -> Advanced, switch Compositing Type.
8. Observer the GoodWeather desklet being transparent.
9. Goto 4.
After login to KDE, the desklet starts on black background.
The desklet should be transparent right from the start.
Is there a temorary workaround available, for instance, programatically
changing the compositing type after desktop startup?
Changed component from kde-runtime to kde-workspace since
compositing is apparently part of kwin. Component version
I think I found the reason for this problem.
For some reason, my ~/.kde/share/config/kwinrc file contained this compositing
Note the "Enabled" setting.
I don't see any setting in the "System Settings" dialog which would enable or
disable compositing entirely. So what I did was to change this to "true" in
vi, then logged out and logged in again, and the desklet's transparency worked
out of the box!
So, here's the question: Where in KDE's "System Settings" dialog can I see
the current enabling state of compositing, and where can I switch compositing
on or off to manipulate the "Enabled" setting in kwinrc?
The checkbox for enabling/disabling compositing is called something like "desktop effects enabled at startup" in the UI. This is a bit misleading because you can use compositing without any effects if you disable all the effects, but it is the way it is. What's strange though is that you should not be able to set a compositing type if compositing isn't enabled in the first place (without enabling it first).
Thank you. I'd never had imagined that the "Enable desktop effects at startup"
button has anything to do with the compositing setting.
As for the ability to switch the compositing type, this setting is always
available, and for some reason it seems to enable desktop effects automatically.
Nevertheless, that has nothing to do with my bug report, which is pretty much
just a cockpit error anyway. I close this bug.
Unfortunately, the upstream developers think "compositing" is a too technical term for normal users to understand. I don't like this vague paraphrasing ("desktop effects" for compositing, "widget" for plasmoid etc.) at all, but it's upstream's choice. :-(