Version: (using KDE KDE 3.5.0) Installed from: Gentoo Packages OS: Linux I found one serious defect with the transparency/shadow effect in kde! if you use a shadow in conjunction with the transparency you will get a darker transparancy, because apparently the shadow is a black semi-transparent copy of the window which is just a little bigger than the original window! this is really stupid, and the shadow should only be drawn outside the window, and not behind it! It makes everything look gray and dull! And I want to use both... Also it looks like shadows are much more cpu intensive than transparancy and effects, maybe limiting the drawing to only around the window, like a new border would help that along also! Also another thing is that, making the shadows bigger than about 2-3 just washes them out... they get so thinly shadowed that they dissapear which isn't what I would want. I would like to have a bigger shadow on my active windows to give the effect of it being higher above the desktop, and inactive ones being lower... however, like this it seems that the shadow gets removed when I get them active. What could be done is add another option to control shadow "filling" to choose how dark it should be, so when upping the size you also up the degree of darkness or filling. Or another algorithm that compensates for it automatically, so what you get is actually a larger shadow! ;) On a positive note though, it works really great now with the new drivers! The only technical problems I have with them is that X just quits if I press view on a "new message" bubble in kopete, it has been like this for a while ( with old drivers too), and the second is that sometimes when I apply changes to the Translucency tab it locks up. Other than that stability has greatly improved! Hope someone can do something about this! other I just thought of two more additions, I think there could be a toggle to still treat a window as active while popups and windows inside the same app appears. And secondly, treat kicker as a seperate thing, so you could still have a transparent kicker while the icons on it are non-transparent! (this one is probably a little harder though) here are some screenshots of what I mean with the shadows: http://huldreveien.generation.no/~wakko/non-shadowed.jpg http://huldreveien.generation.no/~wakko/shadowed.jpg
> treat kicker as a seperate thing, so you could still have > a transparent kicker while the icons on it are non-transparent! this won't happen in KDE3. it requires reworking kicker to use COMPOSITE directly, and that simply isn't in the cards. in KDE4, plasma will do this sort of thing properly.
woww. you're fast. i'd never noticed this behaviour.... ok. first: this isn't serious. crashes are. second: try to look through a semitransparent frontlighted glas. you will see it... throwintg a shadow...! (no really ;) third: look at an object throwing a shadow (one lighht source, preferably) move it closer to the light source and closer to the shadow base (e.g. the floor) you'll notice the shadow... becomes brighter and wider if you near the light and smaller and darker if you near the ground. currently this is a hack. it composite doesn't work perfectly in xaa anyway and afaik kde4 will use a completely other composite manager - so i do certainly not intend to write any customizable shadow engine on this base, sorry
see previous post
I know that' transparent stuff shows shadow, but the problem is that it's ugly... :/ Of course it isn't serious, that's why I posted it as a wish, but I think it's something that should be taken into considerations. I know shadows further away from the floor get's blurred out, but not to the extent, that it is completely gone on the setting 10, when the bar goes to like 100 :P Also it's ugly. The crash I have with kopete is more serious, that should definatly be looked into.. I strongly disagree that all of this is invalid. At least the kopete crash is very valid. Also, some of this info about, transparency and shadows should be available to the developers of the kde4 implementation. I won't reopen it though, that would just be annoying of me, but if you feel I brought any new info to the table feel free to do so.
the kopete bug is known and reported (don't ask me for the number) and it's also maybe rather a X bug (X crashes - as mentioned, composite support on xaa isn't that perfect, may be a problem here) - i'm not sure what kopete does there to trouble the compmgr to trouble X (the code seems to be ok, i don't use kopete or have any irc account or intend to ever have one - so i can't trigger this crash - and unfortunately you don't get a backtrace as X crashes) for the density: the value for the shadow opacity is calculated from the shadow opacity (whether it's wide or narrow) and the window opacity and yes: from a certain point the combined value is zero and the function isn't as smooth as it could be. it's just that before anyone knows where we'll go with X surface it makes hardly sense to put too much effort on those things, as the code will probably be trashed in a short time. this is currently a toy for developers and experienced users as those things are still experimental even on the X side, there's no Qt support and also no freedesktop convention or NET protocol on how to handle those things - what causes troubles (imho, don't hope too much for qt4: the composition currently runs through the cache what makes ARGB on big windows horrible slow and as noone can put pressure on GPU vendors, it may last a while to change this...)
I know this bug is old, but I just recently noticed the problem where the shadow is drawn behind the whole window. It seems to me that it wouldn't be too hard to clip out that part of the shadow image, using an X region or just drawing the image in four pieces (the four sides). It would be nice to have this be corrected before KDE 3.5 is completely dead, and certainly before KDE 4 is completely ready.