Version: 4.4.1 (using KDE 4.4.1) OS: Linux Installed from: openSUSE RPMs Either in window-specific options or inside shadow plugin settings, there should be an option to disable shadow for specific window(s). Good example are apps, which use non-rectangular shape or multiple windows, so shadow looks wrong. Try GNOME Do and you'll see multiple, different shadows one under another.
a shaped window does not receive a shadow by kwin. In that case I'd say that GNOME Do is not a shaped window. Compare to krunner - there is no shadow added by kwin.
neither do undecorated ARGB windows, so a window cannot paint it's own shadows and receive the kwin ones. can you please provide a screenshot? (i have a suspection, but don't know Gnome Go) note that there's also a window property to override shadows (which can e.g. be set by applicaitions)
Created attachment 41817 [details] GNOME Do with KWin - screenshot
> note that there's also a window property to override shadows > (which can e.g. be set by applicaitions) I hope you don't believe GNOME app would add exceptions for KWin (; .
Sure I do ;-) This is however not exactly what i had expected. Do you happen to use the XRender backend?
one other thing just _popping_ into my mind - may this be a "popup" window? (usually they hide if you click somewhere else - if not, try "xprop | grep NET_WM" on it.
> Do you happen to use the XRender backend? No, I'm using OpenGL one. > may this be a "popup" window? It probably is a popup. Its type is set to "splash" and it works as you described it.
(In reply to comment #7) > > may this be a "popup" window? > > It probably is a popup. Its type is set to "splash" and it works as you > described it. It shouldn't do that. Let me cite the specification: "_NET_WM_WINDOW_TYPE_SPLASH indicates that the window is a splash screen displayed as an application is starting up." The window is definately not a splash screen. My fair guess is that it is working around an issue in either Metacity or Compiz. Given the name I do not expect that the developers have ever tried to run GNOME Do with KWin. I would suggest that you report the issue to the GNOME Do developers.
I didn't intend to talk about GNOME do issue here, it's just one programme I'd like to work around somehow different, than changing focus stealing prevention to none. And regarding splash screen definition, true, I agree with it, but Do's window is using splash wm-tip. Issue was reported to them many times. I just want to disable shadow for specific window and I'm looking forward to extending window-specific options.
(In reply to comment #9) > I just want to disable shadow for specific window and I'm looking forward to > extending window-specific options. This requires to write a complete framework, which requires a lot of work. I doubt there will be such a framework in 4.5, so the earliest would be 4.6. That's why I mentioned to ask the GNOME Do developers to fix the issue. (Honestly I'm surprised that kwin allow a splash window to get focus at all) *** This bug has been marked as a duplicate of bug 99198 ***
ok, the shadows then derive from a popup exception in the "no shadows for unique shapes" policy (the reason is that many toolkits/styles provide popups with rounded corners) we could be a little more picky here and check the shape against it's bounding rect, though this would mean overhead for a rare corner case, as - and however: a window with WM_SPLASH + WM_POPUP + a giant empty xshape'd area is just begging for all kinds of troubles (esp. on the focus side, thus clearly a bug on Gnome Do) they likely want to use an override window, manage focus themselves and pot. grab the pointer/kbd this particular item could btw, solved by the rule system (as we as mentioned have a property anyway)