Bug 311995

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 ***