(→‎Using local state in the config file: drop the example given here and instead reference a page that discusses all options)

(8 intermediate revisions by 3 users not shown)

Latest revision as of 05:57, 19 June 2013

This document assumes you're running >= XMonad-0.8.

It describes general tips for configuring xmonad.hs, for example "How to make window X float by default" and others. If you can't find what you're searching for, you may want to look at the Config archive or ask for help on #xmonad@irc.freenode.net.

Also useful, for an overview of how to configure bindings and hooks, and (somewhat out of date) summary of xmonad-contrib extensions, see XMonad.Doc.Extending.

Please add what you found useful, and of course improving existing tips or adding alternatives is highly appreciated!

This example sends Firefox to workspace "web" when it starts. Gajim gets sent to workspace "jabber". Finally, it floats Firefox dialog windows, Gajim and Xmessage windows, and windows with Google or Pidgin as any part of the class name; likewise, any window with VLC anywhere in its title.

The most popular Gimp setups with xmonad are the default of floating all Gimp windows, or using two nested Layout.IM modifiers to put the toolbox and dock panels to either side of some other layout like tabbed or

(MyFavoriteTilingLayout ||| Full)

, plus usually floating tool dialogs with

manageHook

s. Some people combine the toolbox and dock into a single panel. See sample configs below.

To choose how to work with the Gimp in XMonad, it's helpful to understand
the different types of windows as XMonad sees them. If you just want
some example setups, skip to the next section.

All Gimp windows, i.e. those with WM_CLASS class of "Gimp". These windows float if you have

manageHook defaultConfig

anywhere in your

manageHook

. You probably don't want this if you plan to tile even the Gimp tool setting dialogs. Otherwise keep the

manageHook defaultConfig

, and only unfloat the gimp-toolbox, gimp-image-window, and possibly gimp-dock.

Transient or fixed size windows, like file open, ok/cancel, fixed size tool dialogs, etc. XMonad floats these by default for all applications, even without using

manageHook defaultConfig

. If you really want to, you can unfloat specific transients or fixed size windows -- see unfloat above.

Gimp toolbox or dock(s), matched with WM_WINDOW_ROLE(STRING) to use

layoutHook

s or

manageHook

s to place and manage them. Also, with drag and drop you can combine or separate their tabs and panes into one or more windows depending on how you want to use them.

On startup, a default Gimp install creates (1) an empty image window, (2) the toolbox window (brushes, eraser, etc. and their options), and (3) a single dock (layers, paths, etc.) Customize them by dragging tabs to and from existing panels or onto the "create panel separator" on either type of window, (it will highlight when a dragged tab is over it). (It's just below the fg/bg color swatches on the toolbox window.)

from ManageHelpers). These are the many tool settings popups like Levels, Threshold, Curves that normally don't have toolbox tabs. Most people probably want these floated; below is an example of how to do it if you're not starting from all gimp windows being floated.

was the old default before xmonad-0.9, and some people may still have it in xmonad.hs.)
Also, instead of picking the

Full

/

Tabbed

window with ‹mod›-‹tab›, you can add the following to your mouse bindings, to be able to roll the mouse wheel over the Gimp toolbox until the correct window is focused, which seems to prevent the shifting around:

In >xmonad-0.8, the XMonad.Layout.Monitor offers some useful functions for managing such windows as well.

[edit]1.5 Matching specific windows by setting the resource name or class

Sometimes, instead of matching a program's resource name or window class, it is useful to change the program's name and/or class to something easier to detect. This is most useful when starting programs inside terminal emulators, but can also be used to distinguish between, say, editor sessions.

Most X11 programs allow you to specify their resource name and/or class. Usually it's not possible to do so down to the level of individual windows, so you are likely to require WM_WINDOW_ROLE for that. Note that Java-based programs do not support any useful way to set either resource name or window class (bug 6528430).

All Gnome and KDE programs support --name= and --class= options to specify the resource name and class for windows opened by those programs. Use the --help-all option to see these and other low-level options not normally visible.

gnome-terminal by default starts a single back-end "factory" and spawns terminal windows from it; all of these windows will share the same resource name and class. Use the --disable-factory option with --name= or --class= to ensure that the created window is not shared with unrelated terminals.

Other terminal emulators for Gnome and KDE are likely to behave similarly. (Konsole does not, at least as of this writing; but it does send itself to the background, which will break XMonad.Actions.SpawnOn unless you use the --nofork option.) Look for options to disable shared sessions or factories.

Programs such as xterm and the rxvt family of terminal emulators use the standard X11 Xt toolkit, and accept standard toolkit options ("man 7 X"; see the OPTIONS section). Specifically of interest here is the -name option. You cannot set the window class; this is fixed by the toolkit to a constant string supplied by the application developer (see XrmInitialize()).

This combination uses a single backend (urxvtd) which is asked to open terminal windows by urxvtc. These windows will share the same resource name. However, you can use -name to change the resource name of any individual window spawned by urxvtc.
For example:

urxvtc -name weechat -e weechat-curses

The new resource name will be the first component of the WM_NAME property when listed using xprop:

Programs using the standard X11 toolkit use the resource name and class to read configuration information from the app-defaults database and ~/.Xresources. Be careful when changing the resource name to insure that it is not being used to select specific configuration information, or copy that configuration information to the new resource name you are using.

Gtk+ and Qt programs are encouraged but not required to support --name and --class as specified in Gnome and KDE above. Unfortunately, if a given program doesn't support the standard options, it probably doesn't provide any way to control its resource name or class.

When Emacs has been built with support for X11, both -name and --name options should work regardless of the X11 toolkit used. If Emacs only supports running in a terminal, you will need to control the terminal used to run it instead (e.g. "xterm -n myeditor -e emacs somefile".)

As of 2013-03-08, Firefox is abusing the ICCCM (it is technically legal because the ICCCM does not explicitly say it is wrong, it "only" strongly implies it by describing how windows should work on POSIX systems) and changing the resource name for its download manager window to "Download". This means that you cannot match the download manager window for a custom Firefox instance.

For a list of the identifiers used for various keys, see
Graphics.X11.Types and ExtraTypes.

Also, the Util.EZConfig extension allows adding keybindings with simpler syntax, and even creates submaps for sequences like, e.g. "mod-x f" to launch firefox. You can use normal xmonad keybinding lists with its additionalKeys function, or with additionalKeysP, the bindings look like this:

Sometimes, trying different xmonad.hs files, or while dialing in custom key bindings it can be nice to have a reminder of what does what. Of course, just editing or grepping the xmonad.hs is one solution, but for a nice colourized output, try adapting a script like this to your needs:

. While there's plenty of room for improvement in the parsing, this is fine for a quick and dirty display of normal or additionalKeys style bindings. It obviously would need to be changed to parse additionalKeysP style. To have comments displayed, note that it looks for indented comments containing 'eys' so use "Keys" or "keys" in " --" style comments to create keybinding subsections.

Note that in older versions of dzen ^togglecollapse() and ^scrollhome() may not yet be supported. Use something like the following in dzen command line to get similar result:

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:

The Actions.Plane, Actions.CycleWS, and Actions.CycleRecentWS
extensions allow many ways to navigate workspaces, or shift
windows to other workspaces.

Plane is easier to set up, especially if you use Gnome. CycleWS
allows binding to nearly any behavior you'd ever want.
Actions.CycleRecentWS allows swapping with previous or next most
recently viewed workspace similar to how many window managers
cycle windows with alt tab.

In darcs xmonad-contrib (will release as 0.9): Layout.IndependentScreens
simulates dwm style workspaces per screen. For spatial navigation more
general than Plane, i.e. four 3x3 grids of workspaces, see
Actions.WorkspaceCursors.

The Util.Scratchpad module provides a configurable floating terminal that is easily shifted to the current workspace or banished to its own "SP" workspace. Most people want the "SP" tag ignored during workspace navigation. (Note that in xmonad newer than 0.8.*
the scratchpad workspace has been renamed to "NSP".)

Here's one way to do that with Actions.CycleWS, ready to be customized, for example to use HiddenEmptyWSs instead of HiddenNonEmptyWSs, etc.

Note that

notSP

is defined in the where clause of this example. It is
just another name for