Review Request: fix kwin tabbox shadow

[Thomas Lübking]

> On Jan. 6, 2013, 7:34 a.m., Martin Gräßlin wrote:
> > I don't like having a link dependency on plasmagenericshell. If that is supposed to be used, then it needs to go to the workspaces libs.
> > 
> > I also think that this approach just doesn't scale. We use Plasma styled dialogs for more things and I don't want to have to use this approach everywhere and not all of them are C++ based. Furthermore in case of KWin it's a little bit stupid to set an X11 property for the shadows on a KWin internal window.
> > 
> > I will look into the whole thing. I think especially the tabbox has some old code still around which might not be needed any more.
> 
> Xuetian Weng wrote:
>     yep, I totally agree what you said. But as I exam the code I couldn't think of any easier solution that can avoid rewrite this part of code.
>     One of the problem is, the background is defined in qml, so set shadow here isn't correct if someone don't use a plasma background. But maybe the background should be move out, but in that case it would break existing tabbox qml (fortunately there aren't much on kde-look.org).
>     
>     The right approach is to use Plasma::Dialog IMHO, but use it here is not very easy and it would still use same code (which is in kdelibs) to set X11 property for shadow.
>     
>     So kwin will directly use Plasma::Svg for tabbox shadow?.. I can't see a clear way for doing this right so I just take a easiest way for this. (And to call attention for right people on this, on purpose :P)
> 
> Thomas Lübking wrote:
>     KWin needs a (tmp proprietary) property to set the shadow from qml.
>     
>     Item {
>       shadowLeft = <someimage>
>     }
>     
>     Plasma (components) hopefully provides a qml way to access the pixmap(id) of a Plasma::Svg directly, otherwise one will have to create PlasmaCore.SvgItem (i hope they exist) and pass them over to the property (but i've atm. no idea how to make an image out of that)
> 
> Martin Gräßlin wrote:
>     given that KWin includes one layout for Plasma Active which does not set a background at all and which should not get a shadow, anything which would enforce the usage of Shadows is wrong.
>     
>     It needs to be done in a way as Thomas suggests. If that's not possible than we have to live with a regression.
> 
> Aaron J. Seigo wrote:
>     "I don't like having a link dependency on plasmagenericshell. If that is supposed to be used, then it needs to go to the workspaces libs"
>     
>     libplasmagenerichsell is in kde-workspace/libs/plasmagenericshell. it obviously has no dependency on any plasma application or shell since it's in kde-workspace/libs. what more do you want?
>     
>     "We use Plasma styled dialogs for more things and I don't want to have to use this approach everywhere and not all of them are C++ based."
>     
>     if instead of using plasma style dialogs, the code used Plasma::Dialog then it wouldn't be an issue. if there is some reason Plasma::Dialog can not be used, we can perhaps look at why and see if that can be fixed.
> 
> Martin Gräßlin wrote:
>     >> "I don't like having a link dependency on plasmagenericshell. If that is supposed to be used, then it needs to go to the workspaces libs"
>     > libplasmagenerichsell is in kde-workspace/libs/plasmagenericshell. it obviously has no dependency on any plasma application or shell since it's in kde-workspace/libs. what more do you want?
>     When I wrote that I didn't know that it is in libs, I assumed it's not, because the include used "" instead of <> also the name implies that it is about a generic plasma desktop shell. My guessing skills are not that good ;-)
>     
>     >> "We use Plasma styled dialogs for more things and I don't want to have to use this approach everywhere and not all of them are C++ based."
>     > if instead of using plasma style dialogs, the code used Plasma::Dialog then it wouldn't be an issue. if there is some reason Plasma::Dialog can not be used, we can perhaps look at why and see if that can be fixed.
>     KWin is a very special beast, it cannot manage it's own Clients. If it somehow gets a dependency to KWindowSystem it even starts to break as events gets eaten. I don't know if that has been the issue here, but it is quite likely. I remember that for the Qml based TabBox it just didn't work with using the appropriate Plasma Component. It's nice that you want to fix it, but I rather doubt that you want to include fixes for the special needs of a window manager :-)
>     
>     But definetaly using Plasma::Dialog would mean that it has to be Plasma styled. That is already a showstopper for TabBox given that the window strip may not be Plasma styled. Also for Qml based scripts it would turn the you *can* use Plasma style into a you *have* to use Plasma style. I must say that I don't want to have to depend on Plasma styling as that would be considered as a showstopper for any approaches of using KWin in Razor-Qt (they are very interested) and Unity (I have hope since Compiz is dead and Sam no longer employed at Canonical).
> 
> Aaron J. Seigo wrote:
>     so if i am to understand this correctly .. kwin is not using a top level window for tabbox at all, and the issue for the tabbox and this change is that the shadows are no longer *part* of the background? 
>     
>     if that's so, then all that needs be done is to add the shadows by name in the rendering in the tabbox. shadow-top, etc. this can be done easily in the QML itself, and the problem would be solved.
> 
> Martin Gräßlin wrote:
>     erm how?
>     
>         PlasmaCore.FrameSvgItem {
>             id: shadowTop
>             imagePath: "shadow-top"
>         }
>     
>     and if that's possible it should be done for all the OSD and everything which does not have a problem with shadows being part of the window for performance reasons.

> so if i am to understand this correctly
no. it's still a Toplevel window, just not managed by the WM part of KWin (quite like a popup menu)

FTR:
> if that's so, then all that needs be done is to add the shadows by name in the rendering in the tabbox.
Care must be taken for the tabbox since it's used in composited and not composited mode.
In the non-composited mode you naturally don't want shadows.
Needs at least a branch in the qml, reg. all offsets as well.

Those additional offesets must be still provided by the plasma theme, effects like blur etc. must know and handle them.

Frankly, if there's any way to tell kwin (from qml) "here, those are the shadow pixmaps, please tile them around me that way", ie. what's generally done via properties, i assume that to be the less clumsy way in QML and the more consistent part in kwin and esp. keep the shadows outside the window, simplifying things. Cause either we support "shadows are part of the window, please hand those offsets" with all the complexety that currently has - or we don't.
The performance gain should be worth that (also with xcb in mind)


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108224/#review24788
-----------------------------------------------------------


On Jan. 6, 2013, 6:55 a.m., Xuetian Weng wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108224/
> -----------------------------------------------------------
> 
> (Updated Jan. 6, 2013, 6:55 a.m.)
> 
> 
> Review request for kwin, Plasma, Aaron J. Seigo, and Martin Gräßlin.
> 
> 
> Description
> -------
> 
> use the same technique for krunner and some plasma to brought back tabbox shadow.
> 
> 
> Diffs
> -----
> 
>   kwin/CMakeLists.txt 62e9964 
>   kwin/kcmkwin/kwintabbox/CMakeLists.txt 72a6b72 
>   kwin/tabbox/declarative.h e36e67b 
>   kwin/tabbox/declarative.cpp 3bdcfac 
>   powerdevil/daemon/brightnessosdwidget.h ef08903 
>   powerdevil/daemon/brightnessosdwidget.cpp e4cf80a 
> 
> Diff: http://git.reviewboard.kde.org/r/108224/diff/
> 
> 
> Testing
> -------
> 
> compiles, no problem.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130107/60d33b2b/attachment-0001.html>