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

On January 2nd, 2013, 8:54 a.m., Martin Gräßlin wrote:

what about Unmanaged? Yes they are not in the actual stacking order used by KWin, but passed to the effects (see Workspace::xStackingOrder()).

On January 2nd, 2013, 3:02 p.m., Thomas Lübking wrote:

s/stacking/clientStacking/ ?

I'm not entirely sure what those reorders would be of interest (unmanaged are combo dropdowns, popups, tooltips, plasmas panel proxies, the tabbox ...)

At least for the effect(s) of intended use, those are completely irrelevant and given their usual "input only" and/or temporary character, i see no use in "listen & fire" on every minor restack of unmanged windows.

On January 4th, 2013, 7:50 a.m., Martin Gräßlin wrote:

usage: blur effect to know when to schedule a repaint.

Something else that came to my mind. What about the Deleted? Basically the stacking order changes when the Deleted gets removed but not when the Client is removed. I guess emitting an additional signal when the Deleted is destroyed, wouldn't hurt.
the effects get "windowDeleted()" when a window is deleted.
while override_redirect windows will usually only be added or removed, they could indeed alter their stacking order though, yes.

- Thomas


On January 1st, 2013, 12:54 a.m., Thomas Lübking wrote:

Review request for kwin and Martin Gräßlin.
By Thomas Lübking.

Updated Jan. 1, 2013, 12:54 a.m.

Description

So that in the next patch, the slideback effect can be altered to react on this instead of comparing the stacking order in every paint pass.

Testing

Yes, with be::faded.
Order (propagate -> emit) is crucial.

Diffs

  • kwin/effects.cpp (7025883)
  • kwin/layers.cpp (5104e19)
  • kwin/libkwineffects/kwineffects.h (6aea85d)
  • kwin/workspace.h (8416334)

View Diff