Bug 311995 - desktop switcher OSD has no more transparency
Summary: desktop switcher OSD has no more transparency
Status: RESOLVED DUPLICATE of bug 179042
Alias: None
Product: kwin
Classification: Unclassified
Component: general (show other bugs)
Version: 4.9.90 (Beta 2)
Platform: openSUSE RPMs Linux
: NOR minor (vote)
Target Milestone: ---
Assignee: KWin default assignee
: 312059 (view as bug list)
Depends on:
Reported: 2012-12-20 16:28 UTC by Andreas Kuhl
Modified: 2013-06-07 14:26 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:

screenshot (219.99 KB, image/jpeg)
2012-12-20 16:29 UTC, Andreas Kuhl

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Kuhl 2012-12-20 16:28:18 UTC
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
Comment 1 Andreas Kuhl 2012-12-20 16:29:16 UTC
Created attachment 75940 [details]
Comment 2 Martin Flöser 2012-12-20 16:37:03 UTC
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 

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?
Comment 3 Andreas Kuhl 2012-12-20 16:39:04 UTC
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. :/
Comment 4 Thomas Lübking 2012-12-21 22:05:40 UTC
> 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
Comment 5 Martin Flöser 2012-12-22 06:58:25 UTC
*** Bug 312059 has been marked as a duplicate of this bug. ***
Comment 6 Martin Flöser 2012-12-22 07:10:18 UTC
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
Comment 7 Thomas Lübking 2012-12-22 14:24:18 UTC
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
Comment 8 Martin Flöser 2013-01-30 14:15:00 UTC
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

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

Comment 9 Andreas Kuhl 2013-02-19 09:32:28 UTC
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.
Comment 10 Thomas Lübking 2013-02-19 10:58:11 UTC
didn't check for the desktop osd, though.
Comment 11 Andreas Kuhl 2013-05-27 13:07:43 UTC
Bug still present with Kwin 4.10.3 . Any news on this?
Comment 12 Martin Flöser 2013-05-27 13:17:59 UTC
(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
Comment 13 Thomas Lübking 2013-05-27 13:25:54 UTC
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.
Comment 14 pfoo 2013-06-07 14:22:17 UTC
seems fixed in 4.10.4
Comment 15 Andreas Kuhl 2013-06-07 14:24:49 UTC
Works for me in 4.10.4
Thanks for fixing this, looks gorgeous again! :-)
Comment 16 Thomas Lübking 2013-06-07 14:26:16 UTC
Is, thanks for the reminder.

*** This bug has been marked as a duplicate of bug 179042 ***