On Sonntag, 6. Januar 2013 16:37:47 CEST, Aaron J. Seigo wrote:

> it is not a break of API since it isn't API at all. hyperbole 
> helps nothing, so let's not go down that road.

Unilateral change broke things, so technically it's "I" - whether "API" is a 
different matter.

> the change was not done randomly. it puts the shadow drawing 
> where it properly belongs and thereby lets the window be handled 
> correctly with the visual edges (e.g. minus the shadows) being 
> the actual edges of the window.

All true, but i doubt that Martin meant "pointless" but rather "without 
pressure". Given the flamewars on "blocked until frameworks" it's a pretty fair 
question whether it was *necessary* to do it *now*.

Doesn't matter either. Happened. Question is how to deal with the situation.

> so instead of using tested code, you'd prefer a regression 
> visible to the user.

I doubt we can just use the Plasma::Shadow code in KWin elements like the 
tabbox since it operates on QML and not on Plasma Frame (Dialog) directly.

1. it will make kwin link generic-shell what is sematically the gnome/unity 
shell approach.
2. it will visually break non-plasma QMLs (so virtually they're no longer 
supported, see Martins concern in [1])

If a clean solution for shadows in QML (as described in the RR [1]) cannot be 
provided for 4.10 my personal suggestion for 4.10 (only!) would be to 
temporarily copy over the Plasma::Shadow sources (so we also don't have to 
break dependency freeze ;-P) and use them controlled by a property in the QML.

Ideally the property would be sth. tagging that plasma compmenents are loaded 
resp. even better PlasmaCore.FrameSvgItem is used.
In doubt it would have to be an explicit marker.

Notice that this is a dead stupid and cumbersome way to do things [2], but 
should be safe enough (oxygen popups and bespin decoration long time use the 
shadow property for in-process Unmanaged and clients)

Cheers,
Thomas

[1] https://git.reviewboard.kde.org/r/108224/
[2] Instead of dumb copying the shadow implementation of plasma we could maybe 
rather just load the Plasma::Svg and hand over the pixmap(id) internally to the 
Shadow system - less tested, though, but could be then also easily extended to 
proper QML/Component shadow support, thus not pointless either.

Reply via email to