Bug 981665 - transparency of gdesklet erratic in KDE
transparency of gdesklet erratic in KDE
Product: Fedora
Classification: Fedora
Component: kde-workspace (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-07-05 08:40 EDT by Corinna Vinschen
Modified: 2013-07-09 16:39 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-09 07:41:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Corinna Vinschen 2013-07-05 08:40:12 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.
  4. Logout
  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.

Actual results:

  After login to KDE, the desklet starts on black background.

Expected results:

  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?

Comment 1 Corinna Vinschen 2013-07-05 08:57:09 EDT
Changed component from kde-runtime to kde-workspace since
compositing is apparently part of kwin.  Component version
is kde-workspace-4.10.4-5.fc19.x86_64.

Comment 2 Corinna Vinschen 2013-07-05 09:27:06 EDT
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?

Comment 3 Kevin Kofler 2013-07-06 06:03:48 EDT
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).
Comment 4 Corinna Vinschen 2013-07-09 07:41:43 EDT
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.

Comment 5 Kevin Kofler 2013-07-09 16:39:31 EDT
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. :-(

Note You need to log in before you can comment on or make changes to this bug.