Description of problem: Hi, 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 that. - 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): kde-runtime-4.10.4-2.fc19.x86_64 gdesklets-0.36.3-11.fc19.x86_64 gdesklets-goodweather-0.31-11.fc19.noarch 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? Thanks, Corinna
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. Corinna
I think I found the reason for this problem. For some reason, my ~/.kde/share/config/kwinrc file contained this compositing section: [Compositing] AnimationSpeed=3 Backend=OpenGL CheckIsSafe=true Enabled=false GLColorCorrection=false GLLegacy=true GLTextureFilter=2 GLVSync=true GraphicsSystem=raster HiddenPreviews=5 OpenGLIsUnsafe=false UnredirectFullscreen=false XRenderSmoothScale=false 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? Thanks, Corinna
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. Thanks, Corinna
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. :-(