Documentation

The X monad, ReaderT and StateT transformers over IO encapsulating the window manager configuration and state, respectively.

Dynamic components may be retrieved with get, static components with ask. With newtype deriving we get readers and state monads instantiated on XConf and XState automatically.

Virtual workspace indices

Physical screen indices

The Rectangle with screen dimensions

XState, the (mutable) window manager state.

XConf, the (read-only) window manager configuration.

Every layout must be an instance of LayoutClass, which defines the basic layout operations along with a sensible default for each.

All of the methods have default implementations, so there is no minimal complete definition. They do, however, have a dependency structure by default; this is something to be aware of should you choose to implement one of these methods. Here is how a minimal complete definition would look like if we did not provide any default implementations:

• runLayout || ((doLayout || pureLayout) && emptyLayout)
• handleMessage || pureMessage
• description

Note that any code which uses LayoutClass methods should only ever call runLayout, handleMessage, and description! In other words, the only calls to doLayout, pureMessage, and other such methods should be from the default implementations of runLayout, handleMessage, and so on. This ensures that the proper methods will be used, regardless of the particular methods that any LayoutClass instance chooses to define.

An existential type that can hold any object that is in Read and LayoutClass.

Using the Layout as a witness, parse existentially wrapped windows from a String.

The class Typeable allows a concrete representation of a type to be calculated.

Based on ideas in /An Extensible Dynamically-Typed Hierarchy of Exceptions/, Simon Marlow, 2006. Use extensible messages to the handleMessage handler.

User-extensible messages must be a member of this class.

A wrapped value of some type in the Message class.

And now, unwrap a given, unknown Message type, performing a (dynamic) type check on the result.

LayoutMessages are core messages that all layouts (especially stateful layouts) should consider handling.

Existential type to store a state extension.

Every module must make the data it wants to store an instance of this class.

Minimal complete definition: initialValue

Existential type to store a config extension.

Run the X monad, given a chunk of X monad code, and an initial state Return the result, and final state

Run in the X monad, and in case of exception, and catch it and log it to stderr, and run the error case.

Execute the argument, catching all exceptions. Either this function or catchX should be used at all callsites of user customized code.

Same as userCode but with a default argument to return instead of using Maybe, provided for convenience.

Lift an IO action into the X monad

Lift an IO action into the X monad. If the action results in an IO exception, log the exception to stderr and continue normal execution.

Ignore SIGPIPE to avoid termination when a pipe is full, and SIGCHLD to avoid zombie processes, and clean up any extant zombie processes.

Run a monad action with the current display settings

Run a monadic action with the current stack set

True if the given window is the root window

This is basically a map function, running a function in the X monad on each workspace with the output of that function being the modified workspace.

Wrapper for the common case of atom internment

spawn. Launch an external application. Specifically, it double-forks and runs the String you pass as a command to /bin/sh.

Note this function assumes your locale uses utf8.

Like spawn, but returns the ProcessID of the launched application

A replacement for forkProcess which resets default signal handlers.

Use xmessage to show information to the user.

Recompile the xmonad configuration file when any of the following apply:

• force is True
• the xmonad executable does not exist
• the xmonad executable is older than xmonad.hs or any file in the lib directory (under the configuration directory)
• custom build script is being used

The -i flag is used to restrict recompilation to the xmonad.hs file only, and any files in the aforementioned lib directory.

Compilation errors (if any) are logged to the xmonad.errors file in the xmonad data directory. If GHC indicates failure with a non-zero exit code, an xmessage displaying that file is spawned.

False is returned if there are compilation errors.

A trace for the X monad. Logs a string to stderr. The result may be found in your .xsession-errors file

Conditionally run an action, using a Maybe a to decide.

Conditionally run an action, using a X event to decide

If-then-else lifted to a Monad.

Return the path to the xmonad configuration directory.

Return the path to the xmonad cache directory.

Return the path to the xmonad data directory.

Common non-predefined atoms

Common non-predefined atoms

Common non-predefined atoms

Common non-predefined atoms

Safely access window attributes.

All the directories that xmonad will use. They will be used for the following purposes:

• dataDir: This directory is used by XMonad to store data files such as the run-time state file.
• cfgDir: This directory is where user configuration files are stored (e.g, the xmonad.hs file). You may also create a lib subdirectory in the configuration directory and the default recompile command will add it to the GHC include path.
• cacheDir: This directory is used to store temporary files that can easily be recreated such as the configuration binary and any intermediate object files generated by GHC. Also, the XPrompt history file goes here.

For how these directories are chosen, see getDirectories.

Convenient type alias for the most common case in which one might want to use the Directories' type.

Build up the Dirs that xmonad will use. They are chosen as follows:

1. If all three of xmonad's environment variables (XMONAD_DATA_DIR, XMONAD_CONFIG_DIR, and XMONAD_CACHE_DIR) are set, use them.
2. If there is a build script called build or configuration xmonad.hs in ~/.xmonad, set all three directories to ~/.xmonad.
3. Otherwise, use the xmonad directory in XDG_DATA_HOME, XDG_CONFIG_HOME, and XDG_CACHE_HOME (or their respective fallbacks). These directories are created if necessary.

The xmonad configuration file (or the build script, if present) is always assumed to be in cfgDir.