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
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