xmobar - a minimalistic status bar

Table of Contents

1 About

Xmobar is a minimalistic status bar. It was originally designed and implemented by Andrea Rossato to work with xmonad, but it is actually usable with any window manager.

Xmobar was inspired by the Ion3 status bar, and supports similar features, like dynamic color management, icons, output templates, and extensibility through plugins.

These are some xmobar screenshots using the author’s configuration:

This is the changelog for recent releases.

2 Installation

2.1 Using cabal-install

Xmobar is available from Hackage, and you can install it using cabal-install:

    cabal install xmobar

Xmobar versions >= 0.27 require GHC version >= 8.0.2. Due to an intermittent bug in GHC, we recommend using either GHC 8.0.2, 8.2.2 or 8.6.

See below for a list of optional compilation flags that will enable some optional plugins. For instance, to install xmobar with all the bells and whistles, use:

    cabal install xmobar --flags="all_extensions"

2.2 From source

If you don’t have cabal-install installed, you can get xmobar’s source code in a variety of ways:

If you have cabal installed, you can now use it from within xmobar’s source tree:

    cabal install -fall_extensions

There is also a barebones stack.yaml file that will allow you to build the xmobar executable with stances of the form:

    stack install --flag xmobar:all_extensions

2.3 Optional features

You can configure xmobar to include some optional plugins and features, which are not compiled by default. To that end, you need to add one or more flags to either the cabal install command or the configure setup step, as shown in the examples above.

Extensions need additional libraries (listed below) that will be automatically downloaded and installed if you’re using cabal install. Otherwise, you’ll need to install them yourself.

3 Running xmobar

You can now run xmobar with:

    xmobar /path/to/config &


    xmobar &

if you have the default configuration file saved as $XDG\_CONFIG\_HOME/xmobar/xmobarrc (defaulting to ~/.config/xmobar/xmobarrc), or ~/.xmobarrc.

3.1 Signal Handling

Since 0.14 xmobar reacts to SIGUSR1 and SIGUSR2:

4 Configuration

4.1 Quick Start

See examples/xmobar.config for an example.

For the output template:

Other configuration options:

4.1.1 Running xmobar with i3status

xmobar can be used to display information generated by i3status, a small program that gathers system information and outputs it in formats suitable for being displayed by the dzen2 status bar, wmii’s status bar or xmobar’s StdinReader. See i3status manual for further details.

4.1.2 Dynamically sizing xmobar

See this idea by Jonas Camillus Jeppensen for a way of adapting dynamically xmobar’s size and run it alongside a system tray widget such as trayer or stalonetray (although the idea is not limited to trays, really). For your convenience, there is a version of Jonas’ script in examples/padding-icon.sh.

4.2 Command Line Options

xmobar can be either configured with a configuration file or with command line options. In the second case, the command line options will overwrite the corresponding options set in the configuration file.


    xmobar -B white -a right -F blue -t '%LIPB%' -c '[Run Weather "LIPB" [] 36000]'

This is the list of command line options (the output of xmobar –help):

    Usage: xmobar [OPTION...] [FILE]
      -h, -?        --help                 This help
      -V            --version              Show version information
      -v            --verbose              Emit verbose debugging messages
      -r            --recompile            Force recompilation (for Haskell FILE)
      -f font name  --font=font name       Font name
      -N font name  --add-font=font name   Add to the list of additional fonts
      -w class      --wmclass=class        X11 WM_CLASS property
      -n name       --wmname=name          X11 WM_NAME property
      -B bg color   --bgcolor=bg color     Background color. Default black
      -F fg color   --fgcolor=fg color     Foreground color. Default grey
      -A alpha      --alpha=alpha          Transparency: 0 is transparent
                                           and 255 (the default) is opaque
      -o            --top                  Place xmobar at the top of the screen
      -b            --bottom               Place xmobar at the bottom of the screen
      -p            --position=position    Specify position, same as in config file
      -d            --dock                 Try to start xmobar as a dock
      -a alignsep   --alignsep=alignsep    Separators for left, center and right text
                                           alignment. Default: '}{'
      -s char       --sepchar=char         Character used to separate commands in
                                           the output template. Default '%'
      -t template   --template=template    Output template
      -i path       --iconroot=path        Default directory for icon pattern files
      -c commands   --commands=commands    List of commands to be executed
      -C command    --add-command=command  Add to the list of commands to be executed
      -x screen     --screen=screen        On which X screen number to start

    Mail bug reports and suggestions to <mail@jao.io>

4.3 The Output Template

The output template must contain at least one command. xmobar will parse the template and will search for the command to be executed in the commands configuration option. First an alias will be searched (plugins such as Weather or Network have default aliases, see below). After that, the command name will be tried. If a command is found, the arguments specified in the commands list will be used.

If no command is found in the commands list, xmobar will ask the operating system to execute a program with the name found in the template. If the execution is not successful an error will be reported.

It’s possible to insert in the global templates icon directives of the form:


which will produce the expected result. Accepted image formats are XBM and XPM (when with_xpm flag is enabled). If path does not start with "/", "./", "../" it will have iconRoot ++ "/" prepended to it.

It’s also possible to use action directives of the form:

    <action=`command` button=12345>

which will be executed when clicked on with specified mouse buttons. This tag can be nested, allowing different commands to be run depending on button clicked.

4.4 The commands Configuration Option

The commands configuration option is a list of commands information and arguments to be used by xmobar when parsing the output template. Each member of the list consists in a command prefixed by the Run keyword. Each command has arguments to control the way xmobar is going to execute it.

The option consists in a list of commands separated by a comma and enclosed by square parenthesis.


    [Run Memory ["-t","Mem: <usedratio>%"] 10, Run Swap [] 10]

to run the Memory monitor plugin with the specified template, and the swap monitor plugin, with default options, every second. And here’s an example of a template for the commands above using an icon:

    template="<icon=/home/jao/.xmobar/mem.xbm/><memory> <swap>"

This example will run “xclock” command when date is clicked:


The only internal available command is Com (see below Executing External Commands). All other commands are provided by plugins. xmobar comes with some plugins, providing a set of system monitors, a standard input reader, an Unix named pipe reader, a configurable date plugin, and much more: we list all available plugins below.

Other commands can be created as plugins with the Plugin infrastructure. See below.

5 System Monitor Plugins

This is the description of the system monitor plugins available in xmobar. Some of them are only installed when an optional build option is set: we mention that fact, when needed, in their description.

Each monitor has an alias to be used in the output template. Monitors have default aliases. The sections below describe every monitor in turn, but before we provide a list of the configuration options (or monitor arguments) they all share.

5.1 Icon patterns

Some monitors allow usage of strings that depend on some integer value from 0 to 8 by replacing all occurrences of "%%" with it (i.e. "<icon=/path/to/icon_%%.xpm/>" will be interpreted as "<icon=/path/to/icon_3.xpm/>" when the value is 3, also "%" is interpreted as "%", "%%" as "3", "%%%" as "3%", "%%%%" as "33" and so on). Essentially it allows to replace vertical bars with custom icons. For example,

    Run Brightness
      [ "-t", "<ipat>"
      , "--"
      , "--brightness-icon-pattern", "<icon=bright_%%.xpm/>"
      ] 30

Will display bright_0.xpm to bright_8.xpm depending on current brightness value.

5.2 Default Monitor Arguments

Monitors accept a common set of arguments, described in the first subsection below. In addition, some monitors accept additional options that are specific to them. When specifying the list of arguments in your configuration, the common options come first, followed by “–”, followed by any monitor-specific options.

These are the options available for all monitors below:

Commands’ arguments must be set as a list. E.g.:

    Run Weather "EGPF" ["-t", "<station>: <tempC>C"] 36000

In this case xmobar will run the weather monitor, getting information for the weather station ID EGPF (Glasgow Airport, as a homage to GHC) every hour (36000 tenth of seconds), with a template that will output something like:

    Glasgow Airport: 16.0C

5.3 Uptime Args RefreshRate

5.4 Weather StationID Args RefreshRate

5.5 WeatherX StationID SkyConditions Args RefreshRate

For example:

    WeatherX "LEBL"
             [ ("clear", "🌣")
             , ("sunny", "🌣")
             , ("mostly clear", "🌤")
             , ("mostly sunny", "🌤")
             , ("partly sunny", "⛅")
             , ("fair", "🌑")
             , ("cloudy","☁")
             , ("overcast","☁")
             , ("partly cloudy", "⛅")
             , ("mostly cloudy", "🌧")
             , ("considerable cloudiness", "⛈")]
             ["-t", "<fn=2><skyConditionS></fn> <tempC>° <rh>%  <windKmh> (<hour>)"
             , "-L","10", "-H", "25", "--normal", "black"
             , "--high", "lightgoldenrod4", "--low", "darkseagreen4"]

As mentioned, the replacement string can also be an icon specification, such as ("clear", "<icon=weather-clear.xbm/>").

5.6 Network Interface Args RefreshRate

5.7 DynNetwork Args RefreshRate

5.8 Wireless Interface Args RefreshRate

5.9 Memory Args RefreshRate

5.10 Swap Args RefreshRate

5.11 Cpu Args RefreshRate

5.12 MultiCpu Args RefreshRate

5.13 Battery Args RefreshRate

5.14 BatteryP Dirs Args RefreshRate

5.15 BatteryN Dirs Args RefreshRate Alias

Works like BatteryP, but lets you specify an alias for the monitor other than “battery”. Useful in case you one separate monitors for more than one battery.

5.16 TopProc Args RefreshRate

5.17 TopMem Args RefreshRate

5.18 DiskU Disks Args RefreshRate

5.19 DiskIO Disks Args RefreshRate

5.20 ThermalZone Number Args RefreshRate

5.21 Thermal Zone Args RefreshRate

5.22 CpuFreq Args RefreshRate

5.23 CoreTemp Args RefreshRate

5.24 MultiCoreTemp Args RefreshRate

5.25 Volume Mixer Element Args RefreshRate

5.26 Alsa Mixer Element Args

Like Volume, but with the following differences: - Uses event-based refreshing via alsactl monitor instead of polling, so it will refresh instantly when there’s a volume change, and won’t use CPU until a change happens. - Aliases to alsa: followed by the mixer name and element name separated by a colon. Thus, Alsa "default" "Master" [] can be used as %alsa:default:Master%. - Additional options (after the --): - --alsactl=/path/to/alsactl - If this option is not specified, alsactl will be sought in your PATH first, and failing that, at /usr/sbin/alsactl (this is its location on Debian systems. alsactl monitor works as a non-root user despite living in /usr/sbin.). - stdbuf (from coreutils) must be (and most probably already is) in your PATH.

5.27 MPD Args RefreshRate

5.28 MPDX Args RefreshRate Alias

Like MPD but uses as alias its last argument instead of “mpd”.

5.29 Mpris1 PlayerName Args RefreshRate

5.30 Mpris2 PlayerName Args RefreshRate

5.31 Mail Args Alias

5.32 MailX Args Opts Alias

5.33 MBox Mboxes Opts Alias

5.34 NotmuchMail Alias Args Rate

This plugin checks for new mail, provided that this mail is indexed by notmuch. In the notmuch spirit, this plugin checks for new threads and not new individual messages.

5.35 XPropertyLog PropName

5.36 UnsafeXPropertyLog PropName

5.37 NamedXPropertyLog PropName Alias

5.38 UnsafeNamedXPropertyLog PropName Alias

5.39 Brightness Args RefreshRate

5.40 Kbd Opts

5.41 Locks

5.42 CatInt n filename

5.43 UVMeter

6 Executing External Commands

In order to execute an external command you can either write the command name in the template, in this case it will be executed without arguments, or you can configure it in the “commands” configuration option list with the Com template command:

Com ProgramName Args Alias RefreshRate


    Run Com "uname" ["-s","-r"] "" 0

can be used in the output template as %uname% (and xmobar will call uname only once), while

    Run Com "date" ["+\"%a %b %_d %H:%M\""] "mydate" 600

can be used in the output template as %mydate%.

Sometimes, you don’t mind if the command executed exits with an error, or you might want to display a custom message in that case. To that end, you can use the ComX variant:

ComX ProgramName Args ExitMessage Alias RefreshRate

Works like Com, but displaying ExitMessage (a string) if the execution fails. For instance:

    Run ComX "date" ["+\"%a %b %_d %H:%M\""] "N/A" "mydate" 600

will display “N/A” if for some reason the date invocation fails.

7 Other Plugins

7.1 StdinReader

7.2 UnsafeStdinReader

7.3 Date Format Alias RefreshRate

7.4 DateZone Format Locale Zone Alias RefreshRate

7.5 CommandReader "/path/to/program" Alias

7.6 PipeReader "default text:/path/to/pipe" Alias

7.7 MarqueePipeReader "default text:/path/to/pipe" (length, rate, sep) Alias

7.8 BufferedPipeReader Alias [(Timeout, Bool, "/path/to/pipe1"), ..]

7.9 XMonadLog

7.10 UnsafeXMonadLog

7.11 HandleReader Handle Alias

8 The DBus Interface

When compiled with the optional with_dbus flag, xmobar can be controlled over dbus. All signals defined in src/Signal.hs as data SignalType can now be sent over dbus to xmobar. Due to current limitations of the implementation only one process of xmobar can acquire the dbus. This is handled on a first-come-first-served basis, meaning that the first process will get the dbus interface. Other processes will run without further problems, yet have no dbus interface.

An example using the dbus-send command line utility:

    dbus-send \
        --session \
        --dest=org.Xmobar.Control \
        --type=method_call \
        --print-reply \
        '/org/Xmobar/Control' \
        org.Xmobar.Control.SendSignal \
        "string:Toggle 0"

It is also possible to send multiple signals at once:

    # send to another screen, reveal and toggle the persistent flag
    dbus-send [..] \
        "string:ChangeScreen 0" "string:Reveal 0" "string:TogglePersistent"

The Toggle, Reveal, and Hide signals take an additional integer argument that denotes an initial delay, in tenths of a second, before the command takes effect.

8.1 Example for using the DBus IPC interface with XMonad

Bind the key which should {,un}map xmobar to a dummy value. This is necessary for {,un}grabKey in xmonad.

    ((0, xK_Alt_L   ), return ())

Also, install avoidStruts layout modifier from XMonad.Hooks.ManageDocks

Finally, install these two event hooks (handleEventHook in XConfig) myDocksEventHook is a replacement for docksEventHook which reacts on unmap events as well (which docksEventHook doesn’t).

    import qualified XMonad.Util.ExtensibleState as XS

    data DockToggleTime = DTT { lastTime :: Time } deriving (Eq, Show, Typeable)

    instance ExtensionClass DockToggleTime where
        initialValue = DTT 0

    toggleDocksHook :: Int -> KeySym -> Event -> X All
    toggleDocksHook to ks ( KeyEvent { ev_event_display = d
                                    , ev_event_type    = et
                                    , ev_keycode       = ekc
                                    , ev_time          = etime
                                    } ) =
            io (keysymToKeycode d ks) >>= toggleDocks >> return (All True)
        toggleDocks kc
            | ekc == kc && et == keyPress = do
                safeSendSignal ["Reveal 0", "TogglePersistent"]
                XS.put ( DTT etime )
            | ekc == kc && et == keyRelease = do
                gap <- XS.gets ( (-) etime . lastTime )
                safeSendSignal [ "TogglePersistent"
                            , "Hide " ++ show (if gap < 400 then to else 0)
            | otherwise = return ()

        safeSendSignal s = catchX (io $ sendSignal s) (return ())
        sendSignal    = withSession . callSignal
        withSession mc = connectSession >>= \c -> callNoReply c mc >> disconnect c
        callSignal :: [String] -> MethodCall
        callSignal s = ( methodCall
                        ( objectPath_    "/org/Xmobar/Control" )
                        ( interfaceName_ "org.Xmobar.Control"  )
                        ( memberName_    "SendSignal"          )
                    ) { methodCallDestination = Just $ busName_ "org.Xmobar.Control"
                        , methodCallBody        = map toVariant s

    toggleDocksHook _ _ _ = return (All True)

    myDocksEventHook :: Event -> X All
    myDocksEventHook e = do
        when (et == mapNotify || et == unmapNotify) $
            whenX ((not `fmap` (isClient w)) <&&> runQuery checkDock w) refresh
        return (All True)
        where w  = ev_window e
            et = ev_event_type e

9 User plugins

9.1 Writing a Plugin

Writing a plugin for xmobar should be very simple. You need to create a data type with at least one constructor.

Next you must declare this data type an instance of the Exec class, by defining the 1 needed method (alternatively start or run) and 2 optional ones (alias and rate):

    start :: e -> (String -> IO ()) -> IO ()
    run   :: e -> IO String
    rate  :: e -> Int
    alias :: e -> String

start must receive a callback to be used to display the String produced by the plugin. This method can be used for plugins that need to perform asynchronous actions. See src/Xmobar/Plugins/PipeReader.hs for an example.

run can be used for simpler plugins. If you define only run the plugin will be run every second. To overwrite this default you just need to implement rate, which must return the number of tenth of seconds between every successive runs. See examples/xmobar.hs for an example of a plugin that runs just once, and src/Xmobar/Plugins/Date.hs for one that implements rate.

Notice that Date could be implemented as:

    instance Exec Date where
        alias (Date _ a _) = a
        start (Date f _ r) = date f r

    date :: String -> Int -> (String -> IO ()) -> IO ()
    date format r callback = do go
        where go = do
                t <- toCalendarTime =<< getClockTime
                callback $ formatCalendarTime defaultTimeLocale format t
                tenthSeconds r >> go

This implementation is equivalent to the one you can read in Plugins/Date.hs.

alias is the name to be used in the output template. Default alias will be the data type constructor.

After that your type constructor can be used as an argument for the Runnable type constructor Run in the commands list of the configuration options.

9.2 Using a Plugin

To use your new plugin, you need to use a pure Haskell configuration for xmobar, and load your definitions there. You can see an example in examples/xmobar.hs showing you how to write a Haskell configuration that uses a new plugin, all in one file.

When xmobar runs with the full path to that Haskell file as its argument (or if you put it in ~/.config/xmobar/xmobar.hs), and with the xmobar library installed (e.g., with cabal install --lib xmobar), the Haskell code will be compiled as needed, and the new executable spawned for you.

That’s it!

9.3 Configurations written in pure Haskell

xmobar can be used as a pure Haskell program, that is compiled with your specific configuration, expressed as Haskell source code. For an example, see the author’s configuration.

10 Authors and credits

Andrea Rossato originally designed and implemented xmobar up to version 0.11.1. Since then, it is maintained and developed by jao, with the help of the greater xmobar and Haskell communities.

In particular, xmobar incorporates patches by Mohammed Alshiekh, Alex Ameen, Axel Angel, Dhananjay Balan, Claudio Bley, Dragos Boca, Ben Boeckel, Ivan Brennan, Duncan Burke, Roman Cheplyaka, Patrick Chilton, Antoine Eiche, Nathaniel Wesley Filardo, John Goerzen, Reto Hablützel, Juraj Hercek, Tomáš Janoušek, Ada Joule, Spencer Janssen, Roman Joost, Jochen Keil, Lennart Kolmodin, Krzysztof Kosciuszkiewicz, Dmitry Kurochkin, Todd Lunter, Vanessa McHale, Robert J. Macomber, Dmitry Malikov, David McLean, Marcin Mikołajczyk, Dino Morelli, Tony Morris, Eric Mrak, Thiago Negri, Edward O’Callaghan, Svein Ove, Martin Perner, Jens Petersen, Alexander Polakov, Sibi Prabakaran, Pavan Rikhi, Petr Rockai, Andrew Emmanuel Rosa, Sackville-West, Markus Scherer, Daniel Schüssler, Olivier Schneider, Alexander Shabalin, Valentin Shirokov, Peter Simons, Alexander Solovyov, Will Song, John Soros, Felix Springer, Travis Staton, Artem Tarasov, Samuli Thomasson, Edward Tjörnhammar, Sergei Trofimovich, Thomas Tuegel, John Tyree, Jan Vornberger, Anton Vorontsov, Daniel Wagner, Zev Weiss, Phil Xiaojun Hu, Edward Z. Yang and Norbert Zeh.

10.1 Thanks

Andrea Rossato:

Thanks to Robert Manea and Spencer Janssen for their help in understanding how X works. They gave me suggestions on how to solve many problems with xmobar.

Thanks to Claus Reinke for make me understand existential types (or at least for letting me think I grasp existential types…;-).


Thanks to Andrea for creating xmobar in the first place, and for giving me the chance to contribute.

11 Related

12 License

This software is released under a BSD-style license. See license for more details.

Copyright © 2010-2020 Jose Antonio Ortega Ruiz

Copyright © 2007-2010 Andrea Rossato