a) does this only affect the oxygen decoration (change with "kcmshell4 kwindecoration")
b) or only any particular other decoration ;-)
c) is it purely visual (ie. can you still click the titlebar and operate with it, eg. by double clicking, dragging, etc)
d) try "kwin --replace --graphicssystem native &"  - still an issue?

a) this happens only on Oxygen decoration
b) on others decoration looks ok
c) yeah, i can drag window, un-maximixe it minimize and do all other things
d) yes, it's still transparent

My graphics card is Nvidia GeForce GTX 550Ti and I'm using Nvidia proprietary driver, version 290.10

I guess sth. fails on exporting hints from whatever styles OOo in your case (Oxygen/Oxygen-gtk)

I'm using oxygen-gtk 1.1.6 compiled from source.

Can reproduce. Will investigate

From my tests: 

- I can reproduce with other window decorations
(using: QtCurve, and hovering over one of the buttons, waiting for the tooltips to appear)

- I cannot reproduce if I use a different gtk-theme aside from oxygen-gtk.
So likely it is more of a problem of hints between oxygen-gtk and kwin. Thus reassigning.

Ok. The plot thickens. In fact the bug can be reproduce with oxygen and QtCurve as window decoration, but not with e.g. plastik, bespin, others ...

Also, @Thomas (hoping you still read this email)

The issue is related to maximizing a decorated window on which shadow pixmaps are installed (by the style). I can reproduce it with a simple Qt code, namely:

#include <QtGui>
int main(int argc, char** argv)
{
    QApplication app(argc, argv);

    QWidget widget;
    widget.setProperty( "_KDE_NET_WM_FORCE_SHADOW", true );
    widget.resize( 200, 200 );
    widget.showMaximized();
    return app.exec();
}

The reason it is only triggered by libreoffice, because of the crappy way libreoffice uses Gtk (and don't get me started on this): if I want to have shadows on menus and tooltips, I need to install the shadow pixmaps on all windows, whether they are decorated or not ... 

Can that ring any bell ?

(Note: there is no problem for unmaximized windows)

(In reply to comment #8)
> Also, @Thomas (hoping you still read this email)
Yes, kept kwin-bugs in CC ;-)

> The issue is related to maximizing a decorated window on which shadow pixmaps
> are installed (by the style). I can reproduce it with a simple Qt code, namely:
Interesting since -while not by the style- this is what the bespin decoration does all the time.
Since the source of the attribute should not matter

>     widget.setProperty( "_KDE_NET_WM_FORCE_SHADOW", true );
Not tested that code (yet), but does Qt support that property (since afaics dynamic properties are NOT simply stored as X11 properties)

> crappy way libreoffice uses Gtk (and don't get me started on this
No need to do. There's btw also a KDE UI backend for LO (while i've no idea whether it doesn't simply invoke gtk-qt. Menu colors etc. are usually junk here if the button color contrasts the window color...)

> Can that ring any bell ?
No, but i guess there's a conflict between using the decoration built in ("legacy" ;-) shadows and the (new) property based general shadow system (Bespin uses only them and never had the other "i extend the decoration but not really" shadows =)
Possibly related to not painting (some?) shadows for maximized windows.

=> "If we can reproduce it, we can fix it."

"Not tested that code (yet), but does Qt support that property (since afaics
dynamic properties are NOT simply stored as X11 properties)"

No its a dynamic property. But it is used by the oxygen Qt style, to force install shadow pixmaps on a widget, even if it would have guessed not to do so.
Forgot to mention that the example code above works (or rather trigger the bug) only with oxygen style ...

and well, maybe my interpretation of the bug is incorrect.
(but observation is: if I disable passing of the shadows from the gtk style to kwin, I can't see the bug anymore).

(In reply to comment #10)
> No its a dynamic property. But it is used by the oxygen Qt style, to force

Ah, ok - bespin has sth. similar but on a proprietary property.
However if we agree on this one, we could make it canonical (i just wanted to stay away from existing property names to avoid ambiguity)

@Thomas
yes, I'd be in favor of making a canonical widget dynamic property name for forcing the style to install a shadow on it, and same for forcing the style _not_ to install a shadow; and possibly document it on kwin's shadow wiki.
Can be my prop name or any other that you find more appropriate.
At the moment I use: 

_KDE_NET_WM_FORCE_SHADOW
_KDE_NET_WM_SKIP_SHADOW

(and I think only my own applications use them ;))

Maybe having them mimic X property names is a bad idea ... 
You tell me.

@Thomas (again)
The other thing that thickens the plot furthermore is the following: 
oxygen decoration's client, actually removes the _KDE_NET_WM_SHADOW XProperty on window which it is told to manage (the idea was indeed to prevent these kinds of conflicts). But apparently it does it too late. KWin keeps installing one nonetheless ... 
(see again the test above: xprop | grep -i shadow returns nothing, but the shadow is there. (well, in fact, it is there *twice*, once from the style and once from the property -though removed).

So at least I think there is an issue here with kwin, that it does not properly track the deletion of the property. Can you confirm ?

PS: you can check (with oxygen) that it is there twice, if you have the active window glow, since you do then see that there is both the "inactive" dark shadow - from the property - and the glow above, when the window is active ...

This is also true for libreoffice.

... ok and that's probably why QtCurve has the same issue. It does too implement its own shadow, a la oxygen, and not a la Bespin.

Ok, i'll try what's going on there (yet property changes ought to be tracked and createShadow *looks* like capable of dynamically removing them)

about the property: same here - own applications mostly.
I'd rather vote against xproperty/netwm like names, leads to confusion. What about window attribute scheme, but QStyle_ (or KStyle_) instead of WA_

QStyle_forceShadow / -1,0,1 (Off, No, On - prevents having to look up / QVariant cast two props)

> QStyle_forceShadow / -1,0,1 (Off, No, On - prevents having to look up /
> QVariant cast two props)

mmm. Won't that make things quite confusing ? 
(me for instance, am not sure of the difference between Off and No: does Off mean Force Not to Have Shadow, or does it mean Do Not Force Shadow - and let the style decide - and vice-versa for No).

Besides, the incriminated extra cast (and lookup) happens only one, at widget polish. I'd think we can afford this kind of overhead.

Ok, I still have a titlebar in your demo code (Oxygen deco & style; opengl/xrender; raster/native on client and kwin) but thanks to the halo mode in bespin could immediately spot that the KWin shadow is still there (while the property is indeed not)

So runtime withdrawal seems -at least from the deco- to be an issue.

PS

(In reply to comment #17)
> > QStyle_forceShadow / -1,0,1 (Off, No, On - prevents having to look up /
> > QVariant cast two props)
> 
> mmm. Won't that make things quite confusing ? 
Yesno. Could also be a bool alongside QVariant::isValid() - invalid means the property isn't set, means "do whatever you want", true means "please shadow me" and false means "please do NOT shadow me" - too confusing?

https://git.reviewboard.kde.org/r/103751/

Git commit a97bdc64fa2a676f99738abd371a99126fb8e93d by Thomas Lübking.
Committed on 24/01/2012 at 16:58.
Pushed by luebking into branch 'KDE/4.8'.

Support withdrawal of shadows

The Oxygen deco uses this to remove built-in shadows from decorated windows when adding (legacy...) decoration shadows
REVIEW: 103751

M  +3    -0    kwin/shadow.cpp

http://commits.kde.org/kde-workspace/a97bdc64fa2a676f99738abd371a99126fb8e93d

Closing. Thanks Thomas !

PS: I guess you'll also forward port to master ?

no.  i'll merge it ;-)

Git commit c42b7ed8b7abe7e44384a9c59f10eaab53549227 by Thomas Lübking.
Committed on 24/01/2012 at 16:58.
Pushed by luebking into branch 'master'.

Support withdrawal of shadows

The Oxygen deco uses this to remove built-in shadows from decorated windows when adding (legacy...) decoration shadows
REVIEW: 103751
(cherry picked from commit a97bdc64fa2a676f99738abd371a99126fb8e93d)

M  +3    -0    kwin/shadow.cpp

http://commits.kde.org/kde-workspace/c42b7ed8b7abe7e44384a9c59f10eaab53549227

yeah, dream on - merge attempts cause masses of conflicts :-\

I have two Computers with Kubuntu and KDE. One has old radeon that uses r300 driver and there window decoration is ok. Another has brand new geforce which uses proprietary drivers and there decoration is still missing. Try it on computer with nvidia GPU.

This is fixed in 4.8.0

I have 4.8.0 and it still doesn't work on computer with geforce (on computer with radeon it's okay).

Well I'll try home on my nvidia, but I'm pretty sure it did work here.
Sounds like a driver bug ...

1.20 Wednesday, January 18, 2012: KDE SC 4.8 Final Tag

ID: a97bdc64fa2a676f99738abd371a99126fb8e93d
Added by Thomas Lübking 15 days ago

Now get a calendar, a third hand and start counting ;-P

*** Bug 295176 has been marked as a duplicate of this bug. ***