On Fri, Feb 8, 2013 at 5:49 PM, Jochen Keil wrote:

A layout modifier would be as simple as the one I proposed in my initial mail. But making core functionality dependent on a contrib module is a no-go I think.

Doesn't need to be; the current behavior (or alternatives, probably later) is shifted to be the default value of a new field in the Layout record, and contrib modules can then change it. This change should be transparent to all existing modules. If the change is better then that change might be a candidate for migration to the core. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Hello Adam, On 09.02.2013 20:24, adam vogt wrote:

On Thu, Feb 7, 2013 at 5:05 AM, Jochen Keil wrote:

...

Any suggestions how to improve this? Would a patch for making the restacking behaviour configurable be accepted? Restacking the windows could be easily removed from the windows function and implemented as separate module. There it would be easy to implement different stacking behaviors.

Hi Jochen,

One alternative is to keep the ordering in the StackSet as the stacking order, and then have the layout and keybindings have an additional ordering that decides window locations for the layout. In other words, "windows W.shiftMaster" will be your raiseWindow and you have to define an additional 'Stack Window' in the layout (or elsewhere) that decides where windows are put.

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. 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. Imho the general problem lies in the design of the floating layer. I think it should be completely decoupled from the tiling layer (speak: it's own layout). However, that would be cumbersome to implement and certainly not backwards compatible. Therefore I like Brandon's idea of having a separate stacking policy. Unfortunately, this adds another layout method on top of runLayout, so things start to get messy ({?,run,do,pure}Layout). But it would be easy and quick to implement. -- -jrk Denn meine Gedanken Zerreißen die Schranken Und Mauern entzwei: Die Gedanken sind frei.

Hello, On 10.02.2013 01:28, Brandon Allbery wrote:

On Sat, Feb 9, 2013 at 3:01 PM, Jochen Keil 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. Thanks for the clarification! I'm with you that forcing the z-order globally is not a good idea.

...

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. I think now I understand. I forgot about the Layout being a typeclass. So just add new function with a default implementation here. Sorry for getting my wires crossed. :)

so maybe it belongs directly in XConfig instead. Could you then still have different stacking orders for different layouts? I think the stacking order is directly related to the layout which also makes sense in as the View in the MVC model.

(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.) Speaking again in MVC terms: As far as I understand it, XMonad.Operations.windows is the Controller, which should be decoupled from View and Model. Therefore it should not do things which belong to the V or M (e.g. restacking windows).

I'll try to extend the layout class as discussed above and report back in a few days. -- -jrk Denn meine Gedanken Zerreißen die Schranken Und Mauern entzwei: Die Gedanken sind frei.