
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.