On 01/06/12 12:25, Brandon Allbery wrote:

On Thu, May 31, 2012 at 10:03 PM, Michael Norrish mailto:michael.norrish@nicta.com.au> wrote:

When I restart xmonad with a M-q command my xmobar disappears. There's an xmobar process running and it's not obviously blocked. (strace shows it doing things, including recvfrom and writev both with non-zero positive return codes).

Given that you're using the Ubuntu Gnome/Xmonad session, it's trapped under the nautilus desktop window. You probably want to set "lowerOnStart = False" in ~/.xmobarrc.

This seems to do the trick; thanks!

If this isn't sufficient and you need to actively raise it, something like this in the ManageHook might work:

appName =? "xmobar" --> liftX . withDisplay . (io .) . flip raiseWindow =<< ask

This fails with xmonad.hs:122:76: Couldn't match expected type `Endo WindowSet' with actual type `()' Expected type: Display -> Window -> IO (Endo WindowSet) Actual type: Display -> Window -> IO () In the first argument of `flip', namely `raiseWindow' In the second argument of `(.)', namely `flip raiseWindow' But I'll try to get back to the list with a version that works (for future reference). Michael

On 01/06/12 12:55, Brandon Allbery wrote:

*sigh* I always forget mangling it back to the type ManageHook expects...

appName =? "xmobar" --> (liftX . withDisplay . (io .) . flip raiseWindow =<< ask) <+> idHook

and may require extra parentheses depending on how you mix it into an existing ManageHook.

I'm afraid that gives exactly the same error. An earlier post of yours to this mailing list (http://www.haskell.org/pipermail/xmonad/2011-June/011495.html) has

manageUtility :: ManageHook manageUtility = ask >>= \win -> liftX (withDisplay $ \dpy -> io $ raiseWindow dpy win) >> doFloat

The doFloat on the end is necessary to get the type-error to go away. Presumably idHook would be better there, making the entry appName =? "xmobar" --> (ask >>= \win -> liftX (withDisplay $ \dpy -> io $ raiseWindow dpy win) >> idHook) If the .xmobarrc has lowerOnStart set to True, the above doesn't help. (Nor does the version with doFloat.) So, in my situation it looks as if it has to be lowerOnStart = False in the .xmobarrc. Michael