Re: [xmonad] restackWindow / raiseWindow

On 07.02.2013 16:36, Brandon Allbery wrote:

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

...

So far, so good, yet it doesn't work. The reason lies in Operations.hs, specifically in the "windows" function:

io $ restackWindows d (map fst vs)

This makes all my efforts useless. For now I've put the raiseWindow line into the logHook where it works, but I think this is not the right place.

Any suggestions how to improve this? Would a patch for making the restacking behaviour configurable be accepted?

I can't find the original bug where I proposed changing the above to raiseWindow the focused window instead of hammering the entire z-order; but I reference it in < https://code.google.com/p/xmonad/issues/detail?id=346#c13 >. But that change would fix or mitigate a number of issues, and probably make the floating layer issues a bit more tractable. I couldn't find the bug report either. However, I think it all boils down to simply removing the restackWindows line.

It could (and probably should) be argued that stacking belongs in the layout, probably by a new field which existing layouts would default. A global change to the stacking policy would then be a layout modifier along the lines of avoidStruts or smartBorders, plus custom layouts could also replace it at need.

Something atop runLayout? Like so: makeLayout :: Maybe ([a] -> X [a]) -> Workspace WorkspaceId (layout a) a -> Rectangle -> X ([(a, Rectangle)], Maybe (layout a)) Maybe ([a] -> X [a]) would then be a function implementing the stacking policy. Wondering if that would work without further ado. 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. -- -jrk Denn meine Gedanken Zerreißen die Schranken Und Mauern entzwei: Die Gedanken sind frei.