Version: (using Devel) OS: Linux Installed from: Compiled sources There was no problem in 4.2.90, but in 4.2.95 the shadow effect box can be toggled, but there are still shadows. the only way I can turn them off is to disable compositing completely. I have tested this with a new user, with no existing .kde4 directory as well as my regular user. NOTES: using Arch Linux x64 with nvidia 185.* binary
don't use the oxygen deco, try ozone (or any other)
oxygen and ozone seem to have the same behavior. none of the older decorations seem to have the shadows.
the reason is that oxygen paints the shadows itself. i thought ozone would differ in that as well but might be wrong. (and am not sure whether ozone has now become a "symlink" to oxygen anyway...) as there's meanwhile a stable API to do this, more decos may paint their own shadows in the future and i guess there should be a common setting or some api to honor the shadow plugin being up but until then: i assume you'll have to reassign this to oxygen and make it a wish to make the shadows optional.
reassigning to Oxygen - I know they are already aware of this issue. Personally I don't think we should do anything in kwin to work around such problems. Painting the shadows is task of the application, now. Only thing we should do is stating in the shadow that it is possible that shadows are drawn by the decoration - it's kind of an unpleasant situation.
> I don't think we should do anything in kwin to work around imho KWin::KDecoration should provide hints for shadows being enabled and about size/color/offsets - otherwise the deco side shadows and the kwin side shadows might ending up visually incoherent. the other option was to add these settings to each and every deco kcm... what's 1) redundant 2) a little bit inconvenient :-\
(In reply to comment #5) > > I don't think we should do anything in kwin to work around > imho KWin::KDecoration should provide hints for shadows being enabled and about > size/color/offsets - otherwise the deco side shadows and the kwin side shadows > might ending up visually incoherent. Well difficult. That solution would for example break the Aurorae theme engine as it really expects shadows beeing part of the svg. We have to do something in the shadow effect to make it clear what it does and in worst case we just have to remove it for decorated windows and make it clear that decorations have to provide shadows. > > the other option was to add these settings to each and every deco kcm... what's > 1) redundant > 2) a little bit inconvenient :-\ I think it has to be that way that the deco decides. In case of Aurorae shadows are part of the theme. So there will never be the option to enable/disable the shadows as it's part of the svg and removing it would break the theme. I'm really unhappy with this situation :-( Hmm just an idea: we move the shadow settings into kcmdecoration and the decoration can add own costum options. Like we have to groups of settings: one for decorated windows and one for undecorated windows. In case of Oxygen it would be for decorated windows the settings provided by the deco and for undecorated the normal shadow effect. In case of a deco not supporting shadows both groups will show the shadow effect settings. In case of something like Aurorae the decorated settings will just state that shadows are part of the theme and cannot be configured.
I was thinking that we should readd the shadowsActive() call to the decoration API (And maybe backport to 4.3.1) since window shadows are kinda special and are already a part of the API (AbilityProvidesShadow). This is just a boolean call that returns true if the KWin shadow effect is enabled so that the decoration knows if the user wants them or not. Colours, offset and everything else should not be passed to the decoration because if the decoration is doing it's own customized shadow (It's an opt-in thing) then it's because it is designed to look different to the default one (Such as Oxygen's glow) and as such the values for the default shadow will probably be ignored anyway.
colors are one thing (in particular as the "color" will likely be black) but the problem with different offset (ratios!) is that they indicate different light sources (what looks weird, gimp one if you don't trust me ;-) the light model is also connected to the whole app UI (oxygen has a straight toplight, windows from upper left, etc.) therefore the deco sould be able to a) adapt the global offsets, or b) adjust the global offsets to align this. Aurorae could profit from solution 2) and have the implied offset ratios in a config file or as a hidden svg item -> a) user changes deco b) shadow offsets reset to global presets c1) deco reads offsets c2) deco adjusts (temporary) offsets d) global (popups etc) and deco will (can...) use aligned offsets
According to information posted in bug 198704 <https://bugs.kde.org/show_bug.cgi?id=198704>, the shadow plugin no longer controls window shadows--that is up to the window decorator I guess. This change is probably what has contributed to the emergence of the bugs I am experiencing. FYI, Dekorator and Plastik were the decos with rounded corners that I tried. Both of those decos worked fine up until recently (sometime within the last two RC releases).
And I just posted that in the wrong bug report. Whoops! Carry on :D
I can confirm this too. I would expect shadows to be gone completely when I disable shadow plugin, but they don't. And I don't like them much...
I have the opposite problem: I would like to increase the shadow size because it looks more 3D with this. But the shadow-settings do not have an effect (with the oxygene decoration in KDE4.3.2) for decorated windows. Only none decorated windows are affected and this looks like a bug. This is really a bad usability issue for the user (the only good thing is, that it is not so very important ;) ). IMHO there could be different solutions: a) Completely remove the shadow effect setting. (A bad idea, because it is not very KDEish) b) Make clear that this shadow effect setting is only for none decorated windows. (But this would be still confusing.) c) Make Oxygene aware of the shadow settings (this would be the best solution, together with different settings for decorated and none decorated (tooltips, popups, menus) windows. I would choose larger window shadows, but smaller none decorated shadows). As Aurorae AFAIK is not part of KDE, poeple who are using it should know how to turn off the KDE internal shadows by the shadow effect settings. And it would be their problem if they were confused by the shadow effect setting. d) Remove the shadow effect setting and offer this configuration in oxygene settings. (But it would still be great to define 2 shadows, one for decorated and one for none decorated windws. Does Oxygene can affect none decorated windows? If not then d) would be a bad choice). The advantage was that there could be different shadow definitions for different decorations.
in 4.4 the shadow (glow) will be configurable from the Oxygen settings and can be turned off as well. To me this solves the bug.
As announced by Martin: in kde4.4 window decoration shadow is controlled by the decoration (designer's choice. Here kwin). Oxygen shadow decoration is more 'complex' than the kwin effect. It is also configurable, and can be disabled. Right now kwin shadow-effect is still in used for detached toolbars, dropdown menu and tooltips. (due to a Qt limitation). You would have to switch both of them (Oxygen and kwin shadow effect) off, to have no shadow at all.
*** Bug 211305 has been marked as a duplicate of this bug. ***
*** Bug 212540 has been marked as a duplicate of this bug. ***
*** Bug 225654 has been marked as a duplicate of this bug. ***