XMonad：dmenu在启动时不会启动/产生

Question

New to XMonad and loving it so far. I have a fairly vanilla / regular XMonad setup and am having problems with dmenu . When I login and hit mod+p nothing happens. If I then open a terminal and hit xmonad --restart then mod+p , dmenu will be working.

There must be something wrong with my xmonad.hs ? I tried a no-customization setup of XMonad and things were working normally (ie dmenu was working after login).

My questions:

1. Is there something wrong with my xmonad.hs ?
2. Why won't dmenu work unless I xmonad --restart ?
3. Could something fail in xmonad.start that would prevent dmenu from loading properly when starting xmonad?

Here are my files (borrowed from overthink ). :

xmonad.hs

import System.IO
import XMonad
import XMonad.Hooks.DynamicLog
import XMonad.Hooks.ManageDocks
import XMonad.Hooks.SetWMName
import XMonad.Util.EZConfig(additionalKeys)
import XMonad.Util.Run(spawnPipe)
import XMonad.Hooks.ICCCMFocus

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

myManageHook = composeAll
  [ className =? "Gimp" --> doFloat
  , className =? "Vncviewer" --> doFloat
  ]

main = do
  xmproc <- spawnPipe "/usr/bin/xmobar /home/aaron/.xmobarrc"
  xmonad $ defaultConfig { terminal = "urxvt" }
      { manageHook = manageDocks <+> manageHook defaultConfig
      , startupHook = takeTopFocus >> setWMName "LG3D" -- fix for Java apps
      , layoutHook = avoidStruts  $  layoutHook defaultConfig
      , logHook = dynamicLogWithPP xmobarPP
                      { ppOutput = hPutStrLn xmproc
                      , ppTitle = xmobarColor "green" "" . shorten 50
                      }
      , modMask = mod4Mask     -- Rebind Mod to the Windows key
      , workspaces = myWorkspaces
      } `additionalKeys`
      [ ((mod4Mask .|. shiftMask, xK_l), spawn "gnome-screensaver-command --lock") ]

xmonad.desktop

[Desktop Entry]
Encoding=UTF-8
Name=Xmonad-****
Comment=Ligthweight, pretentious tiling window manager
Exec=xmonad.start
Icon=xmonad.png
Type=XSession

xmonad.start

#!/bin/bash

xrdb -merge .Xresources

trayer --edge top --align right --SetDockType true --SetPartialStrut true --expand true --widthtype percent --width 10 --heighttype pixel --height 20 --transparent true --alpha 0 --tint 0x333333 &

# settings daemon is a prereq for some other gnome apps
gnome-settings-daemon &

# Network monitor (connections, vpns) applet in tray
if [ -x /usr/bin/nm-applet ] ; then
    nm-applet --sm-disable &
fi

# volume indicator in tray
if [ -x /usr/bin/gnome-sound-applet ] ; then
  gnome-sound-applet &
fi

eval $(gnome-keyring-daemon --start)
export GNOME_KEYRING_SOCKET
export GNOME_KEYRING_PID

#exec xmonad
dbus-launch --exit-with-session xmonad

Thanks for your help!

Answer 1

I have a vague feeling that when you first launch xmonad, it uses one executable+configuration, and then when you recompile, it finds the "right" one. In xmonad.desktop, try changing the Exec= line to include a full path to your xmonad.start.

Exec=/full/path/to/xmonad.start

Or you might try changing the last line in xmonad.start to include the full path to your xmonad executable.

dbus-launch --exit-with-session /full/path/to/xmonad

Another thing to try is changing the last two lines to:

exec xmonad
#dbus-launch --exit-with-session xmonad

If any of these options change the behaviour you're seeing, that might give us a clue.

---

EDIT: Let's try a different way of launching it, to see if we can learn anything. Don't start any window manager, log into a plain terminal instead. Type the command xinit -- xmonad or xinit -- /full/path/to/xmonad .

Alternatively, create the file .xinitrc with one line in it:

xmonad

Then type the command startx .

I also found this on the Xmonad FAQ, which may help:

2.6 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, eg {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.

Answer 2

UPDATE:

The fix that seems to have solved the problem is changing:

exec xmonad

To:

touch ~/.xmonad/xmonad.hs
exec xmonad

in

/usr/local/bin/xmonad.start (or .xinitrc/.xsession if xmonad is started using startx)

---

OLD:

How about changing:

} `additionalKeys`
 [ ((mod4Mask .|. shiftMask, xK_l), spawn "gnome-screensaver-command --lock") ]

To:

} `additionalKeys`
  [ ((mod4Mask .|. shiftMask, xK_l), spawn "gnome-screensaver-command --lock") 
  , ((mod4Mask, xK_p), spawn "dmenu_run -b -nb black") ]

I had the same issue as you and it was because I had used something like:

((mod4Mask, xK_p), spawn "exe=`dmenu_path | dmenu` && eval \"exec $exe\"")

which, for some reason, only works properly after a "xmonad --restart". Changing the binding to simply "dmenu-run" fixed the problem. In your case, though, it looks like you're missing the binding at all.