[xmonad] restackWindow / raiseWindow

Brandon Allbery allbery.b at gmail.com
Sun Feb 10 01:28:57 CET 2013

On Sat, Feb 9, 2013 at 3:01 PM, Jochen Keil <jochen.keil at gmail.com> wrote:

> I'm not sure if I got you right here. Maybe you could elaborate on what
> you mean by shiftMaster being raiseWindow. I think the additional Stack
> Window parameter in the layout is also what Brandon suggested.

No; I suggested a new *function*, type Maybe Stack -> [Window] -> X (),
which does the raiseWindow or sets stacking order or etc.  aavogt proposes
to keep forcing the z-order globally but provide a way to specify an
alternative order; this strikes me as asking for trouble unless one is
careful to keep both Stacks in sync.

> So far, from my understanding it would be futile to change the stacking
> order in the layout or in a stackset operation because that would then
> be overwritten by the restackWindows call in windows.

Which is why I'm proposing to remove that call and make it instead a
function in the layout, which can be overridden with an alternative.

> on top of runLayout, so things start to get messy
> ({?,run,do,pure}Layout). But it would be easy and quick to implement.

Actually, it's almost completely independent of those; no existing layout
or layout modifier would need to deal with it at all, unless someone wants
to add that functionality (the existing contrib hook to try to keep
floating windows with their owners comes to mind).  Although, this does
make me think that while it's *related* to layout, it's independent of it
to the extent that it has very little to do with the normal places where
layoutHook is run, so maybe it belongs directly in XConfig instead.

(Alternately, get XMonad.Operations.windows out of the stacking business
entirely and put it with the rest of the layout.  It probably belongs there
instead of X.O.windows anyway, and in fact we may already have it being
done in some/all? cases as is; and any situation which requires X.O.windows
to restack windows also requires it to rerun the layout.)

brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20130209/933ebf6d/attachment.htm>

More information about the xmonad mailing list