Xmonad/Frequently asked questions

XMonad

xmonad: frequently asked questions

For configuration tricks, and using xmonad.hs, see Xmonad/General_xmonad.hs_config_tips.

For more documentation, see:

• Building xmonad
• Configuring and extending xmonad
• Extension documentation

When I start xmonad, nothing happens.

Don't panic, this is expected behavior. XMonad is a minimal window manager, meaning it doesn't set a background, start a status bar, display a splash screen or play a soothing sound effect when it starts up. Once xmonad has started, the only thing it does is listen for your first command. Try pressing mod-shift-enter (that is Alt, Shift, and Enter pressed at the same time) to bring up an xterm. Once the xterm appears, use it to read xmonad's man page or point a web browser at http://xmonad.org/tour.html. If no xterm appears, see if any other advice on this page applies.

Installation

What build dependencies does xmonad have?

The hackage page for xmonad lists all dependencies, including:

• Standard Haskell libraries (you might already have these installed):
  • Cabal
  • mtl
  • unix

• Haskell X11 bindings:
  • X11

• C libraries:
  • libX
  • libXext
  • libXinerama

You likely have these already if you've built any programs for X.

xmonad is also availble pre-packaged for many distributions:

• OpenBSD
• NetBSD
• FreeBSD
• Gentoo
• Debian
• Ubuntu
• Arch
• Fedora
• Gobo
• NixOS
• Source Mage
• Slackware

Using your distro package is almost always preferred.

Can I install without root permission?

Yes, the Haskell libraries that xmonad depends on can all by installed in the user package database. Simply append --user to the install phase:

   $ runhaskell Setup.hs install --user

The library will be registered in your ~/.ghc/ database.

How can I use xmonad with a display manager? (xdm, kdm, gdm)

The simplest way is to create or modify your ~/.xsession file to run xmonad. If you don't already have a .xsession, the minimal example looks like:

   xmonad

This requires that the ghc and the xmonad executable (or a symlink to them) are in a directory in the display manager $PATH environment. Alternatively, you can use the full path to xmonad and set ghc's path systemwide. If you do this, you'll also have to change the mod-q binding to use /path/to/xmonad and restart X to have xmonad use the new mod-q (first time only) since the mod-q binding calls xmonad to recompile itself. (See mod-q doesn't work section below.)

People using 'startx' can use these example xinitrc and run-xmonad scripts.

If you are using xdm, you're done. Login and enjoy xmonad.

If you're using kdm or gdm (KDE and GNOME's display mangers, respectively), you're almost done. When logging in, select the entry that says "xsession" or "default session" from the menu in order to use your ~/.xsession to start xmonad.

Alternatively, if you want a menu entry specifically for xmonad, create a file named "xmonad.desktop" in your /usr/share/xsessions (location varies by distribution) directory. For example:

   [Desktop Entry]
   Encoding=UTF-8
   Name=xmonad
   Comment=This session starts xmonad
   Exec=/usr/local/bin/xmonad
   Type=Application

Replace the "Exec=..." line with the actual path to your xmonad executable, and you should be able to login by selecting "xmonad" as a session from the menu in gdm/kdm.

For instructions on using gdm to launch a full GNOME session with xmonad as the window manager read this.

Compiling xmonad on PowerPC and compiler is not interactive

If you have ghc installed and are trying to compile xmonad and your compiler complains about not being interactive, never fear. To compile Setup.hs simply type:

   ghc --make Setup.hs -o Setup
   

Now you can:

   ./Setup configure
   ./Setup build
   sudo ./Setup install
   

If during the build process ghc complains about the "impossible happening", and mentions that you should change something to "-fvia-C", just edit the *.cabal file replacing the line that sets the arguments for ghc, changing "-fasm" to "-fvia-C".

How do I uninstall xmonad?

If you have installed xmonad using your package manager, then just use it. The following applies if you have built xmonad from source code (either darcs or stable release). Let's assume you've installed xmonad to

the $PREFIX (that is, gave --prefix=$PREFIX argument to Setup.lhs configure). If unsure, try your

$HOME and /usr/local as $PREFIX.

 rm  -f $PREFIX/bin/xmonad
 rm -rf $HOME/.xmonad
 rm -rf $PREFIX/lib/xmonad-$VERSION
 # If you have installed XMonadContrib:
 rm -rf $PREFIX/lib/xmonad-contrib-$VERSION

If you have installed xmonad 0.5 or newer, also run

 ghc-pkg unregister xmonad
 # If you have installed XMonadContrib:
 ghc-pkg unregister xmonad-contrib

Do not forget to purge that evil source code!

not found errors or changes to xmonad.hs won't take effect

Ensure that ghc, and the xmonad executable are both in the environment PATH from which you start X. Alternatively symlink them to locations already in the PATH. ghc-pkg list should show ghc, xmonad, X11, etc. without brackets, e.g. {xmonad} is bad. ghc-pkg check will tell you if you have inconsistent dependencies or other registration problems.

The mod-q action calls the xmonad binary to recompile itself, so if your display manager is starting it with /path/to/xmonad you'll also have to edit your xmonad.hs mod-q binding to use the full path and restart X (or in newer versions use 'xmonad --restart') to restart xmonad with the new mod-q full path binding.

If you recently changed ghc versions see #Upgraded GHC and now xmonad xmonad-contrib etc are not found

Configuring xmonad requires GHC, which is 200MB!

Yes. You can use xmonad-light, which allows some of the basic configurations, but if you really want to get the best xmonad experience, you need GHC.

Installing xmonad in a sandbox

This is possible. However ghc needs to know where the sandbox is, so that your configuration can be recompiled. The best way is to set the environment variable GHC_PACKAGE_PATH to /path/to/ghc/db (where you actually started the sandbox).

Configuration

How do I configure xmonad?

By creating and editing the ~/.xmonad/xmonad.hs file, a Haskell source file.

You can use any Haskell you want in this module. The xmonad-contrib package contains many extension modules to make customizing xmonad easier. To have your changes take effect, save the xmonad.hs and either restart (mod-q) or exit X and log back in.

Example configurations are available on the wiki.

For extensive information on configuring, see the links at the top of this page, and the configuration tips page.

Rebinding the mod key (Alt conflicts with other apps; I want the ___ key!)

xmonad uses 'alt', actually mod1, as the default modifier. You may bind to other mod keys by editing your xmonad.hs modMask value, or by using xmodmap to rebind a key to mod1. The apple command key can be rebound to mod1 in this way. Use xmodmap to find what key your mod1 is bound to, as well.

You can rebind the Caps Lock key, to mod, if you wish. See this mailing list item.

If your new key binding doesn't appear to work, double check it doesn't clash with an existing binding.

An example, binding to the mod4 (often 'Win') key:

import XMonad

main = xmonad defaultConfig
         { modMask = mod4Mask
         , terminal = "urxvt"
         }

Multi head and workspaces (desktops)

See also xinerama troubles if your multi-head setup doesn't behave as described below.

XMonad's defaults with multiple monitors may seem confusing and chaotic until explained and illustrated. First we'll look at how things work by default, then at common workspace keybinding customizations.

To focus visible workspaces rather than swapping their screens modify your keybindings as shown in the next section below. See the section about other customizations to give each monitor its own set of workspaces.

The xmonad man page nicely summarizes how multi-head works by default:

When running with multiple monitors (Xinerama, TwinView, xrandr), each screen has exactly one workspace visible. Pressing mod-{w,e,r} switches the focus between screens, while pressing shift-mod-{w,e,r} moves the current window to that screen. When xmonad starts, workspace 1 is on screen 1, workspace 2 is on screen 2, etc. When switching workspaces to one that is already visible, the current and visible workspaces are swapped.

visible workspaces swap (default keybindings): When you have multiple workspaces visible and mod-n to a different visible workspace, your current one swaps with the other one. We'll see how to change that below, if you don't like the swapping -- simply change 'greedyView' to 'view' in your workspace key bindings. To illustrate with two monitors, using the convention "[1*] [3 ]" to mean workspaces 1 and 3 are visible with left monitor the currently active one:

-- 'greedyView' (default) workspace switching (easier to swap visible workspaces)

-- Typical keystrokes are mod-{w,e,r} to a screen, then mod-N a workspace

    [1*] [3 ] -- mod-3 --> [3*] [1 ] -- mod-e, mod-4 --> [3 ] [4*]

    [3 ] [4*] -- mod-w, mod-4 --> [4*] [3 ]

my focus moves instead (custom workspace switching bindings): By replacing the 'greedyView' function with 'view' in the workspace switching bindings you can have your focus shift to the monitor displaying the given workspace, instead of having that workspace 'brought to you.' (See the next section for examples of how to do this.) For example:

-- 'view' workspace switching 

-- (easier to focus another visible workspace, harder to swap)

    [1*] [3 ] -- mod-3 --> [1 ] [3*] -- mod-4 --> [1 ] [4*]

    [1 ] [4*] -- mod-w --> [1*] [4 ] -- mod-4 --> [1 ] [4*]

view users may also want to add key bindings such as shiftNextScreen and swapNextScreen from the xmonad-contrib extension XMonad.Actions.CycleWS.

Replacing greedyView with view

Here is an example of changing your workspace switching bindings to use view rather than greedyView using XMonad.Util.EZConfig's additionalKeysP:

(See contrib docs for EZConfig for more details)

import XMonad
-- skipped
import qualified XMonad.StackSet as W
import XMonad.Util.EZConfig

main = do
    xmonad $ defaultConfig {
        workspaces = myWorkspaces
        -- skipped
        } `additionalKeysP` myKeys

myWorkspaces = ["1","2","3","4","5","6","7","8","9"]

myKeys = [

    -- other additional keys

    ] ++ -- (++) is needed here because the following list comprehension
         -- is a list, not a single key binding. Simply adding it to the
         -- list of key bindings would result in something like [ b1, b2,
         -- [ b3, b4, b5 ] ] resulting in a type error. (Lists must
         -- contain items all of the same type.)

    [ (otherModMasks ++ "M-" ++ [key], action tag)
      | (tag, key)  <- zip myWorkspaces "123456789"
      , (otherModMasks, action) <- [ ("", windows . W.view) -- was W.greedyView
                                      , ("S-", windows . W.shift)]
    ]

For use with additionalKeys or default binding style:

-- as above
myKeys =
    [
    -- other additional keys
    ]
    ++
    [((m .|. mod1Mask, k), windows $ f i) -- Replace 'mod1Mask' with your mod key of choice.
         | (i, k) <- zip myWorkspaces [xK_1 .. xK_9]
         , (f, m) <- [(W.view, 0), (W.shift, shiftMask)]]

Other multi head customizations

By default, XMonad doesn't link all your monitor screens into one workspace like Gnome and friends, neither does it use a model like dwm's where each monitor has its own set of workspaces. To set up dwm style workspaces for each screen, see (0.9 or greater) Layout.IndependentScreens

Screens are in wrong order

With xmonad-contrib newer than 0.8.*, (darcs version), see also XMonad.Actions.PhysicalScreens

Sometimes drivers don't do what you want, and your screens left to right are something weird like 1 0 2, so your mod-{w,e,r} bindings are messed up. Your driver may provide a utility to set screen order, but if not, or if you just don't want to mess with it, here's how to rebind the screen switching bindings:

Note that if you choose not to use myKeys for the key lists appended together with ++ you will need to add parentheses to get something in the form `additionalKeys` ( [......] ++ [.......] ).

Using XMonad.Util.EZConfig's additionalKeysP:

import XMonad
-- skipped
import qualified XMonad.StackSet as W
import XMonad.Util.EZConfig

main = do
    xmonad $ defaultConfig {
        -- skipped
        } `additionalKeysP` myKeys

modm = mod4Mask

myKeys =
    [
    -- other additional keys
    ]
    ++
    [ (mask ++ "M-" ++ [key], screenWorkspace scr >>= flip whenJust (windows . action))
         | (key, scr)  <- zip "wer" [1,0,2] -- was [0..] *** change to match your screen order ***
         , (action, mask) <- [ (W.view, "") , (W.shift, "S-")]
    ]

Using default key binding method or XMonad.Util.EZConfig's additionalKeys:

-- as above
myKeys =
    [
    -- other additional keys
    ]
    ++
    [((m .|. mod1Mask, key), screenWorkspace sc >>= flip whenJust (windows . f)) -- Replace 'mod1Mask' with your mod key of choice.
        | (key, sc) <- zip [xK_w, xK_e, xK_r] [1,0,2] -- was [0..] *** change to match your screen order ***
        , (f, m) <- [(W.view, 0), (W.shift, shiftMask)]]

I don't want the focus to follow the mouse

Easy. There is a setting focusFollowsMouse in the xmonad.hs file; set it to False and restart with mod+q.

How do I configure pointer-follows-focus?

If you are using > xmonad-0.7, you can use the already defined XMonad.Actions.UpdatePointer:

myLogHook = dynamicLogWithPP .... >> updatePointer

For xmonad-0.7, in your config, import XMonad.Actions.Warp from Xmonad contrib and

add this function:

pointerFollowsFocus :: Rational -> Rational -> X ()
pointerFollowsFocus h v = do
    dpy <- asks display
    root <- asks theRoot
    withFocused $ \w -> do
        wa <- io $ getWindowAttributes dpy w
        (sameRoot,_,w',_,_,_,_,_) <- io $ queryPointer dpy root
        if (sameRoot && w == w') then
            return ()
           else
            io $ warpPointer dpy none w 0 0 0 0
                (fraction h (wa_width wa)) (fraction v (wa_height wa))
          where fraction x y = floor (x * fromIntegral y)

Then set the logHook in your config to “pointerFollowsFocus x y”. If you already have a logHook, append “

>> pointerFollowsFocus x y” to it. For example:

myLogHook = dynamicLogWithPP defaultPP { ppCurrent = xmobarColor "#60ff45" ""
                                       , ppVisible = xmobarColor "#fffff0" "" } >> pointerFollowsFocus 1 1

Does xmonad support a statusbar?

Yes. The Hooks.DynamicLog and Hooks.ManageDocks modules are your friends for this purpose.

Arbitrary external programs may be used as a statusbar. See for example dzen or xmobar, an extensible status bar.

xmonad lets you use any application as a 'statusbar', as long as it is visible in a given 'gap' on the screen, and has the override-redirect property set to true. Many status bar/dock programs already set this property, for example, dzen. To set other applications, you can sometimes use normal X resources. For example, to use xclock, launch it with

   xclock -digital -xrm '*overrideRedirect: True' -geometry 1024x30+0+0

If, like xclock, your app doesn't set wm strut properties, so that ManageDocks and avoidStruts automatically leaves a gap, you can do it manually. Import the Layout.Gaps module and, set a gap of, e.g. (30,0,0,0), in xmonad.hs. A similar trick can be done for xsystray.

Also see the Layout.Monitor module.

You can see screenshots of statusbars on the screenshots page.

You can also use Gnome or KDE trays and menus with xmonad. The Hooks.EwmhDesktops, Config.Desktop, Config.Gnome, Config.Kde, etc. modules make desktop environment status bars more useful with xmonad.

To display xmonad logHook output in gnome-panel, see xmonad log applet.

dzen status bars

xmonad's XMonadContrib library comes with a really easy function for getting a status bar working with dzen. To use it, simply have a ~/.xmonad/xmonad.hs containing:

    import XMonad
    import XMonad.Hooks.DynamicLog

	-- 0.9 main:
    main = xmonad =<< dzen defaultConfig
	-- 0.8.1 main:
	main = dzen xmonad

which will launch xmonad with dzen2 if found, set up with nice colours and workspace information. See Don's config example for more information or DynamicLog dzen's documentation.

There is an excellent command-line option and in-text command reference for the SVN version of dzen2 here

gkrellm or other monitors that aren't bars

Gkrellm does not behave like a dock by default. However, there is an option in .gkrellm2/user_config which says dock = 0. If you set it to 1 xmonad will recognize gkrellm as a dock.

Unfortunately gkrellm usually won't hide under other windows regardless of any combination of above and below options in said config file. Opening and closing the gkrellm config usually resolves this (right click the top of gkrellm and select Configure.. from the menu).

In xmonad-darcs (will release as xmonad-0.9) the Layout.Monitor module may be helpful.

Make space for a panel dock or tray

ManageDocks makes it possible for Xmonad to work with panels in the way they expect, automatically leaving the appropriate amount of room for them at the edges of the screen. ManageDocks has been enabled in the example configuration above. By itself, configuration looks like this:

import XMonad
import XMonad.Hooks.ManageDocks
main = xmonad defaultConfig
              { manageHook = manageDocks <+> manageHook defaultConfig
              , layoutHook = avoidStruts  $  layoutHook defaultConfig
              }

Make new windows appear 'below' rather than 'above' the current window

See also the Hooks.InsertPosition module for placement hooks other than W.SwapDown to use in stack order manageHooks.

Force a few tiled windows down

If you only need to position a few windows below rather than above, and can specify window properties that will avoid matching floating dialogs, etc. then adding a few swapDown manageHooks (or similar from Hooks.InsertPosition referenced above) should do the trick.

import XMonad
import qualified XMonad.StackSet as W
main = xmonad defaultConfig
              { manageHook = composeAll
                   [ resource =? "downer" --> doF W.swapDown
                   , title =? "obnoxious window" --> doF W.swapDown
                   , className =? "MPlayer" --> doFloat
                   ]
              }

Limit windows forced down by using composeOne

To position as many windows as possible below the focus while avoiding problems with z-order while using multiple floating windows, use Hooks.ManageHelpers composeOne and (-?>) in place of composeAll and (-->) to specify hooks that only fire if earlier ones have not matched. You can use this to add swapDown last in your composeOne list, so that it's applied only to windows that haven't earlier been floated or identified as transient or dialog windows.

import XMonad
import qualified XMonad.StackSet as W
import XMonad.Hooks.ManageDocks (checkDock)
import XMonad.Hooks.ManageHelpers

main = xmonad defaultConfig
                -- no dialogs, gimp or mplayer windows will get swapped down
                -- since they matched earlier in the composeOne list
              { manageHook = composeOne
                    [ checkDock              -?> doIgnore -- equivalent to manageDocks
                    , isDialog               -?> doFloat
                    , className =? "Gimp"    -?> doFloat
                    , className =? "MPlayer" -?> doFloat
                    , return True -?> doF W.swapDown
                    ]
              }

For a more complex composeOne example, see mauke's manageHooks.

Force all new windows down

(doF W.swapDown is the same as using insertPosition Lower ____.) To avoid problems with floating window dialogs it's highly recommended to also add an isDialog hook as shown below. Adding doF W.swapDown to your manageHook will result in new windows being inserted below the focus; for floating windows this means behind the current window. A minimal config would look like this:

import XMonad
import qualified XMonad.StackSet as W
import XMonad.Hooks.ManageHelpers

main = xmonad defaultConfig
              { manageHook = isDialog --> doF W.shiftMaster <+> doF W.swapDown
                -- 
                -- To prevent unwanted swaps on other workspaces when using
                -- this hook with other doShift hooks, make sure to put
                -- doF W.swapDown furthest to the right, or last in a 
                -- composeAll hook list
              }

Warning: doF W.swapDown without restrictions will result in new floating windows popping up behind focused floating windows, and undesirable focus changes when starting and quickly destroying a window. It is better to only match specific windows to swapDown or use composeOne as shown above.

Avoid the master window, but otherwise manage new windows normally

Note that this is not a good solution for people who use floating windows, since many operations on floats put the floating window into the master position. Some transient windows will be swappedDown to appear below the floating parent unless the user keeps a tiled window in master and floating windows lower in the stack at all times. As with swapDown it's best to use it only on specific windows or at the end of a composeOne list if you use floating windows very often.

-- <snip> 
import qualified XMonad.StackSet as W
import XMonad.Hooks.ManageHelpers
-- <snip>

myManageHook = fmap not isDialog --> doF avoidMaster

-- or if you have other stuff in the managehook, more like
-- myManageHook = (otherStuff) <+> (fmap not isDialog --> doF avoidMaster)

avoidMaster :: W.StackSet i l a s sd -> W.StackSet i l a s sd
avoidMaster = W.modify' $ \c -> case c of
     W.Stack t [] (r:rs) ->  W.Stack t [r] rs
     otherwise           -> c

Prevent new windows from stealing focus

Use a doF W.focusDown manageHook on selected windows, or even on all windows, similar to the swapDown examples above.

For an avoidMaster that keeps the focus with the master instead of focusing the newly created window replace W.Stack t [] (r:rs) -> W.Stack t [r] rs with W.Stack t [] (r:rs) -> W.Stack r [] (t:rs) in the above avoidMaster code.

Firefox annoyances

Stop Firefox from taking focus while using EwmhDesktops

If one uses EWM Hints support, firefox is enabled to choose when you view its workspace, i.e. if you open links from emails or irc or whatever. If you find it annoying... In about:config (vimperator :preferences!) set browser.tabs.loadDivertedInBackground to True to be able to load urls while working elsewhere, then browse them all later when you choose to shift to the firefox workspace. Also ubuntu users may need to disable the ubufox extension.

Firefox's annoying popup downloader

Some applications, notably Firefox 1 and 2, create transient windows not set with the transient property. (e.g. firefox's download manager). When these windows appear, they can take focus and be annoying. For the case of firefox, the 'Download Statusbar' extension is useful for disabling this annoying UI feature.

Watch fullscreen flash video

Since approximately November 2010, the stock configuration no longer causes flash windows to immediately disappear. However, tiling flash's windows is often not what you want. Try some or all of the following hooks.

For browser plugins and most apps, including mplayer floated by manage hook (as in the default manageHook) the following setup allows normal toggling of fullscreen. A few mplayer versions are configured to use a different fullscreen method, but they can be made to work with the isFullscreen hook by adding a line fstype=none to ~/.mplayer/config, or using the -fstype=none flag from the command line. See also the end of the faq regarding using handleEventHook instead.

Add one of the following manageHooks, and modify layoutHook with smartBorders:

-- other imports
import qualified XMonad.StackSet as W
import XMonad.Hooks.ManageHelpers
import XMonad.Layout.NoBorders

main = xmonad defaultConfig {
    -- skipped
    , layoutHook = smartBorders (yourExistingLayoutHook) -- Don't put borders on fullFloatWindows
    , manageHook =  myManageHooks
    }

myManageHooks = composeAll
-- Allows focusing other monitors without killing the fullscreen
--  [ isFullscreen --> (doF W.focusDown <+> doFullFloat)

-- Single monitor setups, or if the previous hook doesn't work
    [ isFullscreen --> doFullFloat
    -- skipped
    ]

If you have multi-head and the focusDown hook doesn't work for you, in darcs xmonad/xmonad-contrib (greater than 0.9.1) XMonad.Hooks.EwmhDesktops has a fullscreenEventHook that is also worth a try. Add it to any existing handleEventHook with <+>, or simply use it as your handleEventHook if you don't already have one. This also is useful for people who prefer tiling mplayer when not fullscreened, or use totem, vlc, or other players that require something like fullscreenEventHook to work at all.

Floating a window or sending it to a specific workspace by default

See General xmonad.hs config tips regarding manageHook, and the section here about 'xprop' for this.

Startup programs

You may launch programs at startup in the usual X manner: by adding them to your .xsession or .Xinitrc. For example, the following .xsession file launches xpmroot to set the background image, xmodmap to rebind caps lock to ctrl. It then launches a status bar program with dzen, before finally launching xmonad:

   # .xsession
   xpmroot ~/.bg/407511721_eb8559457c_o.xpm &
   xrdb -merge .Xresources

   xmodmap -e "remove Lock = Caps_Lock"
   xmodmap -e "keysym Caps_Lock = Control_L"
   xmodmap -e "add Control = Control_L"

   status | dzen2 -ta r -fg '#a8a3f7' \
                        -bg '#3f3c6d' \
                        -fn '-*-terminus-medium-r-normal--16-*' \
                        -e "button1=exec:xterm" & 
   urxvt &

   $HOME/bin/xmonad

You may also launch applications from your xmonad.hs, using startupHook, however this runs each time xmonad is restarted with mod-q. Also in > xmonad-0.8 see spawnPid, mkSpawner, spawnOn.

Use manageHook to arrange your programs on different workspaces by matching various window properties such as className, appName (resource), title, or role.

Using floating windows

Use the regular swap or focus up and down to navigate them, and regular mod-enter to raise a window to the front. For a mod-enter binding, the darcs shiftMaster works better than swapMaster if you use multiple floats over tiled windows. See also this swapDown manage hook warning above. If you use that manageHook on all windows you will create new floats behind existing ones. If you use lots of floats for some reason for better float usability see SimpleFloat layout, FloatKeys, Hooks.Place, and Config.Bluetile in xmonad-contrib.

Setting the X cursor

By default xmonad doesn't set a particular X cursor, which usually means the default X cursor will be used by the system. To set your own custom cursor, use the xsetroot program, as follows, from your startup file, i.e. .xinitrc, .xsession, display manager startup or .Desktop files:

   # For example, a nice left-pointing arrow head cursor

   xsetroot -cursor_name left_ptr

If you have development headers for X11, other cursors can be found in /usr/include/X11/cursorfont.h

Note that some display managers, such as "slim", don't unset the changes they make to the cursor when the window manager starts. This can be worked around by setting the cursor, as above.

Removing the borders around mplayer

You can also use the fullscreen layout, with the NoBorders smartBorders layout modifier, which automatically takes care of most cases.

To add 'smartBorders' to the default tiling modes:

    import XMonad
    import XMonad.Layout.NoBorders

    main = xmonad $ 
            defaultConfig
                { layoutHook = smartBorders $ layoutHook defaultConfig
                -- other fields like terminal, modMask, etc.
                }

You can also remove borders with a key binding using Actions.NoBorders extension. There's drawback: you need manually remove border any time you launch mplayer.

Although this action should be able to be automated, unfortunately you cannot currently use manageHook for this purpose. That's because borders are drawn after runManageHook is executed (see Operations.hs for details).

Alternatively you can manually move the mplayer window 1 pixel to the left and one pixel up by importing XMonad.Actions.FloatKeys and adding a keybinding similar to ((modm, xK_b), withFocused (keysMoveWindow (-1,-1)). (I have not tested yet if this can be used in combination with the manageHook.)

I need to find the class title or some other X property of my program

When using XMonad.Layout.IM, ManageHooks, XMonad.Actions.WindowGo, or several other modules you need to specify detailed information about a window's properties.

See below for a script to nicely format output from the xprop program discussed in detail in this FAQ.

Otherwise, you can generally find what you need by splitting your screen between the window and a terminal; in the terminal, run xprop WM_CLASS or the like, and then click on the window. xprop will print out quite a bit of useful information about the window.

• resource (also known as appName) is the first element in WM_CLASS(STRING)
• className is the second element in WM_CLASS(STRING)
• title is WM_NAME(STRING)

For example, in WM_CLASS(STRING) = "emacs", "Emacs" -- "emacs" is resource (appName), "Emacs" is className.

(Applications may change the title after window creation, before xprop sees it. If possible, use resource or class in such cases.) stringProperty "WM_WINDOW_ROLE" can also be useful.

Sample output might look like:

_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
XdndAware(ATOM) = BITMAP
WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True
                Initial state is Normal State.
                window id # of group leader: 0xf600001
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 257949716
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0xf600013
WM_CLIENT_LEADER(WINDOW): window id # 0xf600001
_NET_WM_PID(CARDINAL) = 476661
WM_LOCALE_NAME(STRING) = "en_US.utf8"
WM_CLIENT_MACHINE(STRING) = "localhost"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified minimum size: 32 by 34
                program specified resize increment: 8 by 17
                program specified base size: 16 by 0
                window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "emacs", "Emacs"
WM_ICON_NAME(STRING) = "emacs@craft"
_NET_WM_ICON_NAME(UTF8_STRING) = 0x45, 0x4d, 0x41, 0x43, 0x53
WM_NAME(STRING) = "EMACS"
_NET_WM_NAME(UTF8_STRING) = 0x45, 0x4d, 0x41, 0x43, 0x53

Note: the last several lines contain useful information like the CLASS and hinting information.

What about other properties, such as WM_WINDOW_ROLE?

Use stringProperty to extract string information, for example:

stringProperty "WM_WINDOW_ROLE" =? "presentationWidget" --> doFloat

For non-string properties, try XMonad.Hooks.ManageHelpers.

Consult the XMonad.ManageHook documentation for more information.

A handy script to print out window information

This script will print window information (if available) in formats usable within xmonad.hs. It is also included in the $src/XMonadContrib/scripts directory with darcs XMonadContrib (>= 0.10).

#! /bin/sh
exec xprop -notype \
  -f WM_NAME        8s ':\n  title =\? $0\n' \
  -f WM_CLASS       8s ':\n  appName =\? $0\n  className =\? $1\n' \
  -f WM_WINDOW_ROLE 8s ':\n  stringProperty "WM_WINDOW_ROLE" =\? $0\n' \
  WM_NAME WM_CLASS WM_WINDOW_ROLE \
  ${1+"$@"}

It works like xprop: by default you click on a window with the crosshairs, or you can specify windows using the -id or -name options. (The -root and -font selectors could be used, but are less than useful. Also, -frame is unlikely to do anything useful.)

See Matching specific windows by setting the resource name or class for how you can change what programs use for some of these strings.

What is the xK_ value for this key?

Pressing the key of interest while focusing a xev window gives useful information. To limit xev's output use something like:

xev | sed -ne '/^KeyPress/,/^$/p'

A complete list can be found at XMonad key symbols.

How can I send a key sequence to a window?

This can be useful when some application uses a hotkey that you want to use in XMonad, yet be able to send the application window the hotkey when needed.

A solution is to use xdotool, which can (among other nifty things), send a fake keypress to the currently focused window. So, for instance, you can use the following keybinding to send Alt+L to the focused window by pressing Ctrl+Alt+L:

   , ((mod1Mask|controlMask, xK_l), spawn "xdotool key alt+l")

xdotool can also paste a line of ASCII text into the focused window. For instance, the following keybinding will insert the email address email@example.org each time the key Ctrl+Alt+e is pressed:

   , ((mod1Mask|controlMask, xK_e), spawn "xdotool text 'email@example.org'")

The XMonad.Util.Paste module (in >= xmonad-contrib-0.9) defines functions to to the same with pure Haskell code.

I don't use a statusbar, but I'd like to have layout displayed for some time when it changes

Let's assume you have import qualified XMonad.StackSet as W in xmonad.hs.

Add the following declaration somewhere in the toplevel:

curLayout :: X String
curLayout = gets windowset >>= return . description . W.layout . W.workspace . W.current

Then add the keybinding:

    , ((mod1Mask, xK_a     ), sendMessage NextLayout >> (curLayout >>= \d->spawn $"xmessage "++d))

You might want to change xmessage to the more friendly program, such as osd_cat, qt-dialog or dzen2.

Another option is to use Layout.ShowWName which has some user configurable options such as font, color and fade timings.

More flexible way is to use dynamicLogString from XMonad.Hooks.DynamicLog (was added after 0.6 release), which can also display current workspace, window name, layout, and even arbitrary [X (Maybe String)], and format them nicely, printing them to xmonad's stdout.

How can I make xmonad use UTF8?

TODO: is this still accurate? Doesn't xmonad-0.8 and greater always use UTF8 with no extra imports or configuration changes?

Due to extensions like DynamicLog, xmonad is capable of text outputting which is not by default but can be encoded in UTF8. Therefore, if you want to output non-ASCII characters, you can take advantage of the System.IO.UTF8 module.

For example using DynamicLog you can define its output ppOutput like his:

import qualified System.IO.UTF8
-- lots of other stuff
ppLog = defaultPP
  { ppOutput = \s -> do
      h <- openFile "/home/$USER/.xmonad/xmonad.log" WriteMode
      System.IO.UTF8.hPutStrLn h s
      hClose h
  }

As it may not be ideal to reopen the file before every writing, you can just place the code somewhere else. See ray's config in xmonad's config archive.

How do I use compositing with xmonad?

Xmonad has the ability to use some compositing features yet still be actually useable ;-). For example, some really nice transparency can be used with a composite aware app like urxvt and xcompmgr.

First enable compositing in your X server configuration by including the following in your xorg.conf

Section "Extensions"
     Option "Composite" "enable"
EndSection

restart the X server and confirm it's working with xdpyinfo | grep Composite. If it returns Composite, then good...

Include this in ~/.Xdefaults

URxvt.depth: 32
URxvt*background: rgba:0000/0000/0000/cccc

this specifies that urxvt uses 32 bit colors and uses a transparent black background. The four c's specify the amount of alpha with ffff being full black and 0000 being fully transparent. You can also use the fading and blurRadius resources to give some nice effects in the transparency. see man urxvt.

finally you need to fire up xcompgr so that this will all actually work. probably you'll want to include it in your ~/.xinitrc or ~/.xsession file:

xcompmgr -c &

the -c option provides a soft shadow around your windows. There are many options, see man xcompmgr.

For an example with screenshots see andrewsw's config in the config archive.

On newer versions of XMonad, see also XMonad.Hooks.FadeInactive documentation.

How do I find a function which does ...?

Hayoo! API search can be used to find existing functions within XMonad and XMonadContrib which do useful things. For example, the search string

(next AND screen) package:xmonad

will find all existing functions which mention moving to the next Xinerama screen.

Troubleshooting

Multi head or xinerama troubles

xmonad does not detect my multi-head setup

To diagnose the problem, execute the following on the command line:

   ghc -e Graphics.X11.Xinerama.compiledWithXinerama

If the output is True, skip to the getScreenInfo test below. If the output is False, your Haskell X11 library was not built against Xinerama. This is true of old Debian and Ubuntu packages, and may also occur if you built from source.

First, be sure that the Xinerama development headers are installed (libxinerama-dev in Debian and Ubuntu).

Next, check the configure output for the Haskell X11 library for the following lines (If using cabal: cabal install X11 -v --reinstall):

   checking X11/extensions/Xinerama.h usability... yes
   checking X11/extensions/Xinerama.h presence... yes
   checking for X11/extensions/Xinerama.h... yes

If any of these lines end in "no", the Xinerama headers are not installed. If the lines end in "yes", execute:

   runghc Setup clean
   runghc Setup configure --user --prefix=$HOME
   runghc Setup build
   runghc Setup install

In the X11, xmonad and xmonad-contrib source directories. Try the compiledWithXinerama diagnostic again, this time it should return True. As always, execute "xmonad --recompile" when reinstalling any part of xmonad.

If compiledWithXinerama is True and multi-head still doesn't work, execute "xmonad --recompile" and press mod-q. If the problem persists, execute this command:

   ghc -e "Graphics.X11.openDisplay [] >>= Graphics.X11.Xinerama.getScreenInfo"

Here is a sample output from a system with two 1280 by 1024 monitors, oriented side by side:

   [Rectangle {rect_x = 0, rect_y = 0, rect_width = 1280, rect_height = 1024}, Rectangle {rect_x = 1280, rect_y = 0, rect_width = 1280, rect_height = 1024}]

Check to see whether there is a Rectangle corresponding to each of your screens. If there is not, and the compiledWithXinerama diagnostic returns True, there may be a problem with your X server configuration. The most common one is having your monitors set to clone one another. See 'man xrandr', or, if using the proprietary nvidia drivers, 'nvidia-settings' to see how reconfigure them.

Also, there can be two versions of the X11 haskell library installed, one of them built with Xinerama, and other without it. If XMonad is using the one built with Xinerama, and the output of the commands use the version without it, all these tests will work but these problems will persist. Check the output of ghc-pkg to see if there is more than one version of X11 installed.

Missing X11 headers

Your build will fail if you've not installed the X11 C library headers at some point. ./configure for the Haskell X11 library will fail. To install the X11 C libs:

• debian

   apt-get install libx11-dev

X11 fails to find libX11 or libXinerama

Cabal has difficulty locating library directories on some platforms (such as the Mac or RHEL4). First, locate the directory that contains libX11.so (libX11.dylib on Mac OS X). Add the following line to the .cabal file for the package:

   extra-lib-dirs: /your/path/here/
   

For example, on a 64 bit machine you might need to add:

   extra-lib-dirs: /usr/X11R6/lib/lib64
   

You can also add the paths to your .buildinfo file, or set the LD_LIBRARY_PATH environment variable.

Something is weird with multi head windows or workspaces (desktops)

See Configuration: Multi head and workspaces

Configuring xmonad to show in-process Xinerama diagnostic information

The following will allow you to display a message box with the above-mentioned Xinerama diagnostic information when you press Ctrl-Mod-Shift X.

   import qualified Graphics.X11
   import qualified Graphics.X11.Xinerama
   import Data.List (intercalate)
   
   ...
   
   xineramaDebug :: X ()
   xineramaDebug = do
     rectangles <- liftIO $ Graphics.X11.openDisplay [] >>= Graphics.X11.Xinerama.getScreenInfo
     -- Really ought to quote xinerama and show rectangle, but this will
     -- do for now.
     spawn ("xmessage \""
            ++ "Compiled with Xinerema: "
            ++ show Graphics.X11.Xinerama.compiledWithXinerama ++ "\n"
            ++ "Rectangles:\n"
            ++ intercalate "\n" (map show rectangles)
            ++ "\"")

and add the following to your additionalKeys:

   ((mod1Mask .|. shiftMask .|. controlMask, xK_x), xineramaDebug)

(and you may need to add X11 as a dependency in your cabal file).

X Error of failed request: BadAccess (attempt to access private resource denied)

This message seen at xmonad's stdout when starting xmonad means that another window manager is already running. If the other WM was started from a DE, you can use Util.Replace to have xmonad ask the other WM to exit before starting up. Note: If exiting your previously running wm would lead to your X session ending, then this method won't work.

Otherwise refer to the appropriate page for starting xmonad instead of your other WM (Gnome, KDE).

mod-q doesn't work

Upgraded GHC and now xmonad xmonad-contrib etc are not found

When you change ghc versions you need to rebuild or reinstall haskell libraries to make sure they are compatible and registered with the new ghc. Often your distro packagers will try to make this as automatic as possible, by making it just happen. Or at least they will make it easier, e.g. gentoo's ghc-updater and haskell-updater. (This isn't just a Haskell/ghc issue; it's true for other languages, too: c.f. python-updater scripts, distro policies regarding gcc and glibc changes.)

Changes to the config file ignored or 'xmonad not found' when starting X

Both ghc and xmonad must be in your display manager init's $PATH when starting X and xmonad for reconfiguration by mod-q. Make sure the environment from which you start xmonad has the appropriate settings.

When changing the xmonad.hs and restarting with mod-q, xmonad will attempt to exec the xmonad binary. This means it must be in your $PATH environment variable, or the exec will fail silently and the old xmonad instance keeps running.

With xmonad 0.5 and later, mod-q will also call ghc on your ~/.xmonad/xmonad.hs file, and will continue with defaults if ghc is not found.

Additionally, if you change and reinstall the haskell-X11 or XMonadContrib library, changes to that package will not be noticed by xmonad's recompilation checker, so xmonad.hs won't be recompiled. (needs confirmation: is this true?) To fix this:

   xmonad --recompile

after reinstalling the contrib library.

Tabbed or other decorated layouts not shown

Both xmobar and xmonad's default Theme use the -misc-fixed-*-*-*-*-10-*-*-*-*-*-*-* font by default. This is possibly the most commonly installed font in the *nix world, but if it's not installed, or core fonts aren't working for some reason, you'll have problems. Without the font you have set in your Theme....

tabs and other decorated layouts will simply not draw. There should be font related errors in .xsession-errors or wherever your display manager directs stderr to help confirm that this is the cause of missing decorations. xmobar will spit out a cryptic error message and refuse to run.

Check with xfontsel that you have the fixed 10 font if you want to use the defaults. For xft, check that your xmonad and xmobar were compiled with xft support. (They are by default on most distros) Then customize your theme by using something like the following in your layoutHook

myTabbed = tabbed shrinkText defaultTheme {
          fontName = "xft:terminus:size=12" -- choose an installed font
          -- more theme customizations
        }

main = do
    -- skipped
        , layoutHook = avoidStruts $ myTabbed ||| layoutHook defaultConfig
    }

DE panels pagers or EwmhDesktops are broken (just upgraded to >0.8)

Starting with 0.9, EwmhDesktops users must change configuration by removing the obsolete ewmhDesktopsLayout from layoutHook, (it no longer exists), and updating to the current ewmh support which still includes a logHook, but in place of the old layout modifier, uses a startupHook and handleEventHook (see ff.).(No need to change config if using ewmh via Config.Desktop, Config.Gnome, etc. Your config will automatically be updated to use current ewmh support.)

Users of defaultConfig that explicitly include EwmhDesktops hooks and the ewmhDesktopsLayout modifier should remove them and instead use the new ewmh function which adds EWMH support to defaultConfig all at once. You should keep avoidStruts and manageDocks if you're using them.

The 0.9 way to use EwmhDesktops rather than a desktop config is:

import XMonad
import XMonad.Hooks.EwmhDesktops

main = xmonad $ ewmh defaultConfig {
        -- normal customizations
        }

defaultGaps doesn't work any more! (just upgraded to >0.7)

See Make space for a panel section: use XMonad.Hooks.ManageDocks avoidStruts for this instead of Gaps, or import XMonad.Layout.Gaps.

Showing fractions of lines in gvim, urxvt,etc.

This is due to certain layouts doesn't care about so called size hints (resize increments) specifically the WM_NORMAL_HINTS(WM_SIZE_HINTS) (use xprop to see it). This, combined with certain programs, like gvim, which doesn't check if it gets enough size to render the last line and uses it anyway render this annoying behaviour. Aside from patching the offending program, you can:

1. Use a layout which uses these size hints like Hinted Grid, or HintedTile
2. Use the layoutHints modifier on any layout
3. Workaround in .vimrc. These lines in your .vimrc lets you change the number of lines with F4/Shift-F4:

  map <F4> :let &lines=&lines-1<CR>
  map <S-F4> :let &lines=&lines+1<CR>

4. Change the color of default GTK background (white lines), to match gvim background

  style "vimfix" { bg[NORMAL] = "#000000" }
  widget "vim-main-window.*GtkForm" style "vimfix"

Emacs mini-buffer starts at wrong size

ontoillogical says: Most people turn off menus and toolbars and adjust fonts in their .emacs. That's what breaks emacs' display in tiling WMs. To get emacs to look correctly, move all of the stuff that affects how emacs draws a frame to .Xdefaults/.Xresources

For reference here is the relevant section of mine:

Emacs.font: DejaVu Sans Mono-12
Emacs.fontBackend: xft
Emacs.menuBar: off
Emacs.toolBar: -1
Emacs.verticalScrollBars: off

If you're having emacs sizing problems setting these in .Xdefaults is still worth a try even if you don't have any custom .emacs settings.

Losing text when resizing xterms

Being a dynamic tiling window manager, xmonad, like ion or dwm, makes heavy use of resizing. Clients such as xterm, might not take well to resizing and the window might require a refresh (Ctrl-L). To minimize this, several users recommend urxvt (rxvt-unicode), which handles resizing much better.

I just resized my terminal, but the terminal app didn't resize.

This is a SIGWINCH bug in the Linux kernel, believe it or not, in the 2.6.26 series. Details here: http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/8044876def45c0b0/4b7f4cd87feafe5e?show_docid=4b7f4cd87feafe5e.

The simplest solution is to up/downgrade to a kernel version without this bug.

Double encoding of command lines in ghc 7.8 and later

Because earlier versions of ghc had runtimes that just truncated characters, use of Unicode outside the range '\0' .. '\255' required that xmonad and utilities (notably http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Util-Run.html) encode such to UTF-8 before passing them to e.g. executeFile.

ghc 7.8 and later perform this encoding themselves, leading to double encoding from functions such as spawnPipe. (spawn would not have been affected in versions of xmonad that do not use the utf8-string package; current versions are affected.)

A quick way to work around this is to

   import qualified GHC.IO.Encoding as GIO

at the top of xmonad.hs, and then as the first thing in your main put

   GIO.setFileSystemEncoding GIO.char8

which will restore the old behavior. Bugs have been recorded against the main offenders, so they can be updated to behave correctly according to the ghc version.

XMonad is frozen!

XMonad stops but the current window still responds to keys

Usually this is because a dynamicLog is writing to a pipe handle that's not being read. For example the xmonad.hs writes to some status bar in the logHook, but the status bar is not installed, not in $PATH, not set up to read its stdin, or just plain not running. Eventually the pipe fills up and blocks and xmonad waits for it to be read before continuing.

To cat the full pipe and free up xmonad, find xmonad's pid via pgrep or htop, etc. let's say it's 1001, then ls -l /proc/1001/fd/ and look for the largest numbered pipe. Let's use 4. Then cat /proc/1001/fd/4 to unblock xmonad so you can fix your xmonad.hs and xmobarrc to work correctly. (If catting that pipe doesn't spew out a bunch of stuff and unfreeze things, try the others listed.)

With the post 0.9 =<< xmobar and statusBar modifiers it isn't obvious that xmonad is writing to a pipe. If you don't want xmonad info shown in your status bar, you will probably be better off launching it by other means such as .xinitrc. You can also customize your PP's ppOutput field to use the default hPutStrLn to write to stdout, or change it to \s -> return () to do nothing at all.

With xmobar, if your logHook is writing to its stdin via ppOutput = hPutStrLn foo, make sure the .xmobarrc commands include a Run StdinReader line, and the template includes %StdinReader%.

For examples of an .xmobarrc with working StdinReader, see this arch linux help page or John Goerzen's xmonad config tutorial.

See also this issue on the xmonad bug tracker.

XMonad stops responding to keys (usually due to unclutter)

The number one cause for this is the 'unclutter' program, which can fool some clients into thinking they've lost the pointer, when in fact they have not. See the '-noevents' flag to unclutter. Or use XMonad.Actions.Warp or XMonad.Actions.UpdatePointer xmonad-contrib extension instead.

An app seems to have frozen and xmonad stops responding to keys

Often you can get X to behave again by running 'xclock -display :0' on the appropriate display via ssh or from a virtual terminal. If that's not enough kill suspect apps similarly.

There is also an option in (pre evdev versions of) xorg.conf which enables the key combination Ctrl+Alt+Keypad-Divide to break active keyboard and mouse grabs.

This may allow xmonad to continue normally in such cases. To enable this key combination, add the following line to your xorg.conf in the Section Server Flags then restart X:

   Option         "AllowDeactivateGrabs" "on"

Problems with Java applications, Applet java console

There are two classes of problems: blank, grey windows and windows that can't be focused for keyboard input. The latter should be fixed in the newest xmonad, so follow the instructions on the website for getting a copy of the darcs repository and build it. Remember to rebuild xmonad-contrib (preferably also from darcs) afterwards! The remainder of this section covers the blank, grey window problems.

The Java gui toolkit has a hardcoded list of so-called "non-reparenting" window managers. xmonad is not on this list (nor are many of the newer window managers). Attempts to run Java applications may result in `grey blobs' where windows should be, as the Java gui code gets confused.

Preferred Method

If you are using openjdk6 >= 1.6.1, the cleanest way to work around the hardcoded list is to warn the vm that xmonad is non-reparenting by exporting the appropriate environment variable:

_JAVA_AWT_WM_NONREPARENTING=1

Using JDK 7 seems to work well, too, see below.

Using SetWMName

Otherwise, you can lie to Java about what window manager you are using, by having the SetWMName extension convince Java that xmonad is "LG3D". (**WARNING: This *breaks* recent versions of gtk+3!** Use the Preferred Method above instead, if necessary upgrading your Java to a version which supports it.) Normally you would use this in the startup hook, like this:

-- etc
import XMonad.Hooks.SetWMName

main = do
    xmonad $ defaultConfig
    { modMask = mod4Mask
    , startupHook = setWMName "LG3D"
    -- other customizations
    }

However, modules using Hooks.EwmhDesktops, such as Config.Gnome, Config.Desktops, etc. also set WM Name as part of supporting Extended Window Manager Hints. Combining EWMH support with the "LG3D" workaround takes special attention to modifying the appropriate hook for your xmonad version:

Starting with xmonad-0.9. the window manager name is set once in EWMH startupHook after each mod-q, along with other EWMH initialization, but after that can be changed and not overwritten till the next mod-q. See below for example startupHooks combining both startupHooks.

In xmonad versions 0.7 and 0.8 the EWMH configs setWMName to "xmonad" on each logHook event, so to use "LG3D" instead, it's necessary to either

• patch the XMonad.Hooks.EwmhDesktops source and rebuild xmonad-contrib

OR

• use the version 0.8.* hack shown below to repeatedly setWMName "LG3D" after the ewmh logHook runs.

Using SetWMName with EwmhDesktops

For xmonad-0.9 0.9.1 or darcs:

Add ewmhDesktopsStartup, (or 'startupHook gnomeConfig', etc.) to startupHook before setWMName.

Defining the EWMH hooks yourself:

-- etc
import XMonad.Hooks.EwmhDesktops
import XMonad.Hooks.SetWMName

main = xmonad defaultConfig
      { -- skipped
      , startupHook = ewmhDesktopsStartup >> setWMName "LG3D"
      }

Using a desktop config as your base:

    xmonad desktopConfig
      { -- skipped
      , startupHook = startupHook desktopConfig >> setWMName "LG3D"
      }

If instead you're using the ewmh config modifier to add EWMH support, then define your config at top-level to allow over-riding the startupHook definition with your own version:

-- etc
import XMonad.Hooks.EwmhDesktops
import XMonad.Hooks.SetWMName

-- define an EWMH base config to use later in main
conf = ewmh defaultConfig
      { manageHook  = myManageHooks <+> manageDocks <+> manageHook defaultConfig
      , layoutHook  = avoidStruts $ myLayout ||| layoutHook defaultConfig
      , logHook     = dynamicLogWithPP xmobarPP
                          { ppOutput = hPutStrLn xmproc
                          , ppLayout = const ""
                          , ppTitle = xmobarColor "green" "" . shorten 80
                          }
      }

-- Override the WM Name setting for the "LG3D" workaround
-- but still use the rest of the EWMH base config you just
-- defined, including its startupHook ewmh initialization

main = do
    xmproc <- spawnPipe "xmobar"
    xmonad conf
        { startupHook = startupHook conf >> setWMName "LG3D"
        }

For xmonad-0.8.* :

-- etc
import XMonad.Hooks.EwmhDesktops
import XMonad.Hooks.ManageDocks
import XMonad.Hooks.SetWMName

main = do
    xmproc <- spawnPipe "xmobar"
    xmonad $ defaultConfig
      { manageHook = myManageHooks <+> manageDocks <+> manageHook defaultConfig
      , layoutHook = avoidStruts $ ewmhDesktopsLayout $ myLayout ||| layoutHook defaultConfig
        -- NOTE: no '$' is used between dynamicLogWithPP and xmobarPP
      , logHook    = dynamicLogWithPP xmobarPP
                          { ppOutput = hPutStrLn xmproc
                          , ppLayout = const ""
                          , ppTitle = xmobarColor "green" "" . shorten 80
                          }
                     >> ewmhDesktopsLogHook
                     >> setWMName "LG3D"

      ---- or with a desktop config, e.g.
      -- , logHook = logHook gnomeConfig >> setWMName "LG3D"
      }

With xmonad-0.9 or greater there is no need to spam the X server with setWMName in logHook, see above for how to modify startupHook instead.

Changing AWT Toolkit

Another option is to use an AWT toolkit that is more window manager agnostic, (Some report that this causes keyboard to fail in some java applications. It also doesn't seem to work as widely or reliably as setWMName or other preferred methods above.) If you want to try it, set the environment variable:

  AWT_TOOLKIT=MToolkit

This seems to fix some versions of:

• MATLAB
• cgoban3
• Netbeans
• processing [1]

Even if you don't use Bash, you can often set environmental variables by putting them in .profile and logging back in:

  export AWT_TOOLKIT=MToolkit

Using the free blackdown java runtime also seems to work correctly to fix this issue.

Use JDK 7

• Using JDK 7 also seems to work well.

Anthony Brown writes:

I just downloaded and early binary release of JDK 7 and it looks like the new Java version behaves properly ... I tried using some Gui apps that gave me the infamous grey windows with Java6 (or Java5 without setting AWT_TOOLKIT=MToolkit) and so far no problems occured.

Gunnar Ahlberg #xmonad:

JDK 7 solved problems remaining even when using setWMName "LG3D" in logHook.

Persuade a java application to use a specific java runtime (JRE)

Sometimes it turns out that a program works with a specific JRE version, but not with another. Commercial programs tend to ship with their own JRE, so you may even notice that one program works while another doesn't. (For example, I've had a setup where Maple had problems while Matlab behaved well.) A java symlink in the right place can do wonders here. See this Ubuntu bug report for a number of examples.

XMonad doesn't save my layouts and windows

xmonad will remember your workspace layouts during dynamic restart (mod-q), but not when quitting X altogether. Note that this means if you add or remove layouts to the config.hs file, the changes won't be noticed during a hot-restart (the state from the previous session will be used).

You can reinitialise the xmonad state dynamically with mod-shift-space.

Some keys not working

If you've an unusual keyboard, X may not know precisely which keys you've bound xmonad actions to. An example is when you use a French keyboard layout. You may need to set your own mod key, or use different key bindings in xmonad.hs. See the xmonad.org docs on configuring and customizing for advice on rebinding keys. Also currently xmonad only handles the first of duplicate key symbols bound, so if you have for example multiple xK_Backspace keys not all will be bound. There are patches available on the xmonad mailing list (or darcswatch) to change this.

Media keys

XMonad.Util.EZConfig additionalKeysP or Graphics.X11.ExtraTypes are the best way to bind the XF86 family of special keys. Note that some special laptop keys are handled by acpi and may show up as button events instead, or even bypass X completely.

French keyboard workspace switching

See XMonad.Config.Azerty for an azertyConfig to use in place of defaultConfig. This will adjust keybindings for the azerty layout, fixing workspaces switching, etc.

Numeric keypad keys like xK_KP_2 not working

Bind to the non-numeric versions of these keys. They work regardless of NumLock status. To avoid conflicts with other apps you probably want to use them with modifiers. Here is an example of using them to navigate workspaces in the usual mod-N mod-shift-N way, but on the key pad:

myWorkspaces = ["1","2","3","4","5","6","7","8","9","0"]
 
modm = mod4Mask -- win key for mod
 
myKeys = -- use with EZConfig.additionalKeys or edit to match your key binding method
    [
    -- more custom keybindings
    ]
    ++
    [((m .|. modm, k), windows $ f i)
        | (i, k) <- zip myWorkspaces numPadKeys
        , (f, m) <- [(W.greedyView, 0), (W.shift, shiftMask)]]
    ]
 
-- Non-numeric num pad keys, sorted by number 
numPadKeys = [ xK_KP_End,  xK_KP_Down,  xK_KP_Page_Down -- 1, 2, 3
             , xK_KP_Left, xK_KP_Begin, xK_KP_Right     -- 4, 5, 6
             , xK_KP_Home, xK_KP_Up,    xK_KP_Page_Up   -- 7, 8, 9
             , xK_KP_Insert]                            -- 0

Keybindings dont work with rdesktop

Try running with the "-K" (keep window manager key bindings) switch. For example, rdesktop -K -f 666.666.666.666 then press Ctrl-Alt-Enter, or simply rdesktop -K 666.666.666.666

Copy and Paste on the Mac

When using X11 for Mac OS X, and you switch from the quartz WM to xmonad, you can lose copy/paste functionality between X windows and normal Mac apps. To fix this, and restore copy and paste, add

   quartz-wm --only-proxy &

in your .xinitrc above the line that runs xmonad. It will capture and syncronize copy/paste events in both environments. More specifically, it mirrors OS X copy actions into both PRIMARY and CLIPBOARD, but only CLIPBOARD into OS X paste.

OpenOffice looks bad

OpenOffice won't use (strangely) the GTK look, unless the following environment variable is set:

   OOO_FORCE_DESKTOP=gnome

Use this if you don't like the default look of OpenOffice in xmonad.

Help! xmonad just segfaulted

Due to this bug in GHC's recompilation checker,

   http://hackage.haskell.org/trac/ghc/ticket/1372

if you updated a previously built xmonad, or XMonadContrib, when a dependent library has changed in the meantime, GHC will happily go ahead and link your libraries together, into a broken binary. This will at best produce a linker error, and at worst, a version of xmonad that will segfault.

The rule is: when rebuilding, for example, XMonadContrib, always clean first if any library it depends on has changed.

   runhaskell Setup.lhs clean

You may also want to make sure your config gets rebuilt:

   xmonad --recompile

Another possibility is your xmonad was compiled against a very old version of the haskell-x11 library. Use haskell-X11-1.4.2 or newer. This version incorporates a couple of WM_HINTS related segfault bug fixes.

Cabal: Executable stanza starting with field 'flag small_base description'

When using ghc 6.6, or old versions of Cabal, you may get errors when configuring:

   *** Exception: getSection got a line without a '{'.  Consider this a bug.

These are all symptoms of trying to compile xmonad with an old version of cabal.

The darcs version after xmonad 0.4 switched to requiring Cabal 1.2 to build xmonad. You must have Cabal 1.2 or newer to build xmonad older than 0.4. It will work fine with ghc 6.6.1, and you do not need to updated ghc. This will also not break older packages. Get cabal from Hackage:

   http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Cabal

Build and install as usual, then rebuild xmonad.

To build Cabal with ghc 6.6.1 you will also need the filepath library, which is also (of course) available from hackage:

   http://hackage.haskell.org/cgi-bin/hackage-scripts/package/filepath

configure: error: cannot run C compiled programs.

This typically means that you have /tmp mounted with noexec. To use another directory, make an alias that temporarily changes $TMPDIR, like

alias cabal="TMPDIR=[insert directory here, eg ~/.cabal/build but make sure the directory exists] cabal"

A manage hook is having no effect

If a manage hook that checks an attribute of a window(e.g. resource =? "foo" --> bar) doesn't work even though the property is the same as reported by xprop, it can be caused by a program setting the corresponding property after the window has been created. To debug whether or not the term on the right hand side is at fault, it is useful to log which resource (or other property) xmonad sees:

(resource >>= io . appendFile "/home/<youruser>/xmonad_debug" >> idHook)

If opening the desired window causes xmonad to produce a log entry with the resource you were interested in, it means that the term on the right-hand side of --> is not working.

Is there an Xmonad equivalent for Wayland?

As of this writing, https://github.com/L-as/waymonad appears to be actively maintained.