Hi Peter, It looks like composeOne picks the first action that matches. So I think you'll get what you describe from: composeOne [ isFloating -?> doCenterFloat , pure True -?> insertPosition Below Newer ] You've given me an idea for a new contrib module: specifying which window gets focus after the last one closes should be done in contrib... sort of the opposite of InsertPosition. I think doing that reliably involves a handleEventHook. I think the event to watch would be ones with the DestroyWindowEvent constructor and nothing relevant turns up when I grep contrib, so it probably hasn't been written yet. Regards, Adam On Nov 4, 2015 12:16 PM, "Peter Jones" wrote:

I love that insertPosition can keep new windows from going into the master area, but there's one small annoyance w.r.t. transient floating windows.

I'm using `insertPosition Below Newer` with `composeOne`. When a password dialog appears, and the master window previously had the focus, the dialog gets focused and is put in the center of the screen. That part is perfect.

The problem comes when I dismiss the dialog. At that point I would expect the master window to regain focus, but one of the slave windows does instead. Of course, removing `insertPosition` fixes my issue.

This is what I have in my configuration in an attempt to avoid this issue:

composeOne [ pure True -?> insertPosition Below Newer , isFloating -?> doCenterFloat ]

`isFloating` comes from XMonad.Hooks.FadeWindows and I have it in there hoping to *not* apply `insertPosition` when the current window is already floating.

Any suggestions?

-- Peter Jones, Founder, Devalot.com Defending the honor of good code

_______________________________________________ xmonad mailing list xmonad@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

Peter Jones writes:

I'm using `insertPosition Below Newer` with `composeOne`. When a password dialog appears, and the master window previously had the focus, the dialog gets focused and is put in the center of the screen. That part is perfect.

The problem comes when I dismiss the dialog. At that point I would expect the master window to regain focus, but one of the slave windows does instead. Of course, removing `insertPosition` fixes my issue.

I was finally able to write a configuration to get insertPosition to work the way I want. I moved all my manage hooks into composeOne and added the transience manage hook. Here is my final manage hook: manageHook :: ManageHook manageHook = manageDocks <> composeOne [ -- Some application windows ask to be floating (I'm guessing) but -- it's stupid to float them. title =? "HandBrake" -?> normalTile -- HandBrake file dialog asks for crazy sizes. , className =? "Handbrake" <&&> isDialog -?> forceCenterFloat -- Force dialog windows and pop-ups to be floating. , isDialog -?> doCenterFloat , stringProperty "WM_WINDOW_ROLE" =? "pop-up" -?> doCenterFloat , className =? "Gcr-prompter" -?> doCenterFloat , transience -- Move transient windows to their parent. -- Tile all other windows using insertPosition. , pure True -?> normalTile ] where normalTile = insertPosition Below Newer -- Peter Jones, Founder, Devalot.com Defending the honor of good code