13 Feb
2012
13 Feb
'12
8:52 p.m.
On Tuesday 14 February 2012 00:07:57 Timothy Pearson
wrote:
Those shadows in KDE3.5.10 I think, in fact, composited. They work
satisfactory for me.
The original shadows have an extensive settings dialog in kcontrol and
more features
than those from Chakra project. For example the shadows can be set to
appear or not when resizing and moving windows.
Those shadows from Chakra are not displayed when moving windows.
The original shadows also can be enabled separately for menus, active and
non-active windows, and their size also
can be set separately. There is also an option for different shadow color.
http://storage3.static.itmages.ru/i/12/0214/h_1329165438_7516085_4b941fd1da…
And this is how the shadows look like:
http://storage9.static.itmages.ru/i/12/0214/h_1329165743_2170554_d5f80f5a0b…
Yep, those are the kompmgr composited shadows, which are present in TDE
and are the ones I want to keep. The other shadows in question are not
composited and are very glitchy as a result.
Tim
I suspect
this patch was introduced before the final KDE 3.5.10 was
released, when KDE still had no shadow function in kwin.
I do agree that if shadow code has been duplicated, the broken code
should
be removed. I seem to remember KDE 3.5.10 having badly broken shadows,
though at this distance I could be mistaken.
Actually, with all the repairs I made to kompmgr, and given the inherent
bugginess of the non-composited kwin shadow code, I'd like to see the
non-composited shadows removed altogether. Non-composited fading has a
similar problem IIRC, although I have not tested it as I run kompmgr
exclusively on my systems. 
