The desktop switcher OSD was transparent in previous KWin versions but is opaque since beta 1 of 4.10.0. Please see attached screenshot. Reproducible: Always Steps to Reproduce: 1. enable switcher OSD 2. switch desktop Actual Results: OSD is opaque Expected Results: OSD is transparent
Created attachment 75940 [details] screenshot
I have to trace it down. It might be that the script is loaded before the compositor is fully initialized causing the script to use the opaque theme elements. Just for clarification: with "before it was working" you mean it used to work with 4.9 and not a random snapshot from git master?
Correct, it was working with 4.9 and stopped working with 4.10 beta 1. I did not test any earlier 4.10 snapshots than beta1. Thx for looking into this, I did note this regression earlier but failed to report it until now. :/
> It might be that the script is loaded before the compositor is fully initialized > causing the script to use the opaque theme elements. Should plasma not automatically adjust to the presence of a compositor (what if i start w/o compositing and toggle it on later)? Would it fall into categories of bug #179042
*** Bug 312059 has been marked as a duplicate of this bug. ***
I'm not sure whether it's related to bug #179042. Somehow I think it must be somewhere else as I currently have a * correct Plasma * correct KRunner * correct EffectFrame but I have brokeness in: * Tabbox * Desktop change OSD * close button in Present Windows (but filter frame is correct) Very strange
Filter is effectframe, closebutton, tabbox and Desktop OSD are top level windows. Tabbox is 32bit, closebutton should - DOSD will likely be ;-) The plasma panel has a shadow property here (not mine, ie. from style or deco -> must come from plasma) and i guess it should on those windows as well then. The issue will likely be around KWindowSystem::compositingChanged() and the issues we had (PA; Marco involved, iirc) reg. KWindowSystem utilization inside kwin (but that is just a gut feeling) - not entirely bug #179042, though
Git commit 0be3da58b8a219e458cc0c80027f3bf7f0421ee5 by Martin Gräßlin. Committed on 16/01/2013 at 14:50. Pushed by graesslin into branch 'KDE/4.10'. Use translucent/dialogs/background elements where possible In effects it's obvious that compositing is enabled, so specifying the translucent element is no problem. In tabbox a context property "compositing" is injected which decides whether "translucent" or "opaque" elements should be used. Here the translucent elements are only used if the Blur effect is available - for this a new Effect::Feature Blur is introduced and in addition it is tested whether the theme provides the translucent element. Also the masking is adjusted to ensure that only the shadow is not blurred. Reason for this change is that Plasma theme seems not always to pick up whether compositing is used when used from inside KWin. It does not cover the Desktop Change OSD which uses PlasmaCore.Dialog and there we cannot (yet) inject that we use compositing. Overall I'm quite unhappy with this patch and I do hope we can fix it in the proper place in the lifetime of 4.10 and revert this patch. REVIEW: 108438 M +11 -0 kwin/effects/blur/blur.h M +6 -2 kwin/effects/desktopgrid/desktopgrid.cpp M +6 -2 kwin/effects/presentwindows/presentwindows.cpp M +1 -1 kwin/libkwineffects/kwineffects.h M +17 -2 kwin/tabbox/declarative.cpp M +1 -0 kwin/tabbox/qml/CMakeLists.txt M +10 -8 kwin/tabbox/qml/ShadowedSvgItem.qml M +1 -1 kwin/tabbox/qml/clients/big_icons/contents/ui/main.qml M +1 -1 kwin/tabbox/qml/clients/compact/contents/ui/main.qml M +1 -1 kwin/tabbox/qml/clients/informative/contents/ui/main.qml M +1 -1 kwin/tabbox/qml/clients/present_windows/contents/ui/main.qml M +1 -1 kwin/tabbox/qml/clients/small_icons/contents/ui/main.qml M +1 -1 kwin/tabbox/qml/clients/text/contents/ui/main.qml M +1 -1 kwin/tabbox/qml/clients/thumbnails/contents/ui/main.qml M +12 -8 kwin/tabbox/qml/desktop.qml http://commits.kde.org/kde-workspace/0be3da58b8a219e458cc0c80027f3bf7f0421ee5
Hmmm, this was indeed fixed with your commit but seems now broken once more with KWin 4.10.0. Screenbrightness OSD and window close button in present windows effect both have transparancy while desktop switcher OSD is opaque.
https://git.reviewboard.kde.org/r/108947/ didn't check for the desktop osd, though.
Bug still present with Kwin 4.10.3 . Any news on this?
(In reply to comment #11) > Bug still present with Kwin 4.10.3 . Any news on this? I am no longer able to reproduce on 4.11
This should be fixed for good when i commit https://git.reviewboard.kde.org/r/107983/ (intended for tonight) We can then hopefully also remove al* handcrafted "i know your theme" direct plasma path manipulations from kwin.
seems fixed in 4.10.4
Works for me in 4.10.4 Thanks for fixing this, looks gorgeous again! :-)
Is, thanks for the reminder. *** This bug has been marked as a duplicate of bug 179042 ***