--===============6420095963594999796== Content-Type: multipart/alternative; boundary="===============3752047912472221670==" --===============3752047912472221670== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > On Jan. 2, 2013, 8:54 a.m., Martin Gr=C3=A4=C3=9Flin wrote: > > what about Unmanaged? Yes they are not in the actual stacking order use= d by KWin, but passed to the effects (see Workspace::xStackingOrder()). > = > Thomas L=C3=BCbking wrote: > s/stacking/clientStacking/ ? > = > I'm not entirely sure what those reorders would be of interest (unman= aged are combo dropdowns, popups, tooltips, plasmas panel proxies, the tabb= ox ...) > = > At least for the effect(s) of intended use, those are completely irre= levant and given their usual "input only" and/or temporary character, i see= no use in "listen & fire" on every minor restack of unmanged windows. > = > Martin Gr=C3=A4=C3=9Flin wrote: > usage: blur effect to know when to schedule a repaint. > = > Something else that came to my mind. What about the Deleted? Basicall= y 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 ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108059/#review24413 ----------------------------------------------------------- On Jan. 1, 2013, 12:54 a.m., Thomas L=C3=BCbking wrote: > = > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/108059/ > ----------------------------------------------------------- > = > (Updated Jan. 1, 2013, 12:54 a.m.) > = > = > Review request for kwin and Martin Gr=C3=A4=C3=9Flin. > = > = > Description > ------- > = > So that in the next patch, the slideback effect can be altered to react o= n this instead of comparing the stacking order in every paint pass. > = > = > Diffs > ----- > = > kwin/effects.cpp 7025883 = > kwin/layers.cpp 5104e19 = > kwin/libkwineffects/kwineffects.h 6aea85d = > kwin/workspace.h 8416334 = > = > Diff: http://git.reviewboard.kde.org/r/108059/diff/ > = > = > Testing > ------- > = > Yes, with be::faded. > Order (propagate -> emit) is crucial. > = > = > Thanks, > = > Thomas L=C3=BCbking > = > --===============3752047912472221670== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
This is an automatically generated e-mail. To reply, visit: http://git.revie= wboard.kde.org/r/108059/

On January 2nd, 2013, 8:54 a.m., Martin Gr= =C3=A4=C3=9Flin wrote:

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

On January 2nd, 2013, 3:02 p.m., Thomas L=C3=BCbking wrote:

s/stackin=
g/clientStacking/ ?

I'm not entirely sure what those reorders would be of interest (unmanag=
ed 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 unma=
nged windows.

On January 4th, 2013, 7:50 a.m., Martin Gr=C3=A4=C3=9Flin wrote:= 

usage: bl=
ur 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 Clien=
t is removed. I guess emitting an additional signal when the Deleted is des=
troyed, 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=C3=BCbking wrote:

Review request for kwin and Martin Gr=C3=A4=C3=9Flin.
By Thomas L=C3=BCbking.

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

Descripti= on 

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

Testing <= /h1> 
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
--===============3752047912472221670==-- --===============6420095963594999796== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kwin mailing list kwin@kde.org https://mail.kde.org/mailman/listinfo/kwin --===============6420095963594999796==--