wmii

git clone git://oldgit.suckless.org/wmii/
Log | Files | Refs | README | LICENSE

introduction.tex (7571B)


      1 \chapter{Introduction}
      2 
      3 \wmii\ is a simple but powerful window manager for the X Window
      4 System. It provides both the classic (“floating”) and tiling
      5 (“managed”) window management paradigms, which is to say, it does
      6 the job of managing your windows, so you don't have to. It also
      7 provides programability by means of a simple file-like
      8 interface, which allows the user to program in virtually any
      9 language he chooses. These basic features have become
     10 indispensable to the many users of \wmii\ and other similar
     11 window managers, but they come at a cost. Though our penchant
     12 for simplicity makes \wmii's learning curve significantly
     13 shorter than most of its competitors, there's still a lot to
     14 learn. The rest of this guide will be devoted to familiarizing
     15 new users with \wmii's novel features and eccentricities, as
     16 well as provide advanced users with an in-depth look at our
     17 customization facilities.
     18 
     19 \section{Concepts}
     20 
     21 As noted, \wmii\ provides two management styles:
     22 
     23 \begin{description}
     24   \item[Managed] This is the primary style of window management
     25     in \wmii. Windows managed in this style are automatically
     26     arranged by \wmii\ into columns. Columns are created and
     27     destroyed on demand. Individual windows in the column may be
     28     moved or resized, and are often collapsed or hidden
     29     entirely. Ad-hoc stacks of collapsed and uncollapsed windows
     30     allow the user to efficiently manage their tasks. When
     31     switching from an active to a collapsed window, the active
     32     window collapses and the collapsed one effectively takes
     33     its place.
     34 
     35     Managed windows have an unadorned titlebar:
     36 
     37     \titlebar{managed}
     38 
     39   \item[Floating] Since some programs aren't designed in ways
     40     conducive to the managed work flow, \wmii\ also provides the
     41     classic “floating” window management model. Windows managed
     42     in this model float above the managed windows and may be moved
     43     freely about. Other than automatic placement of new windows
     44     and snapping of edges, \wmii\ doesn't manage floating
     45     windows at all.
     46 
     47     Floating windows are indicated by a decorated titlebar:
     48 
     49     \titlebar{floating}
     50 
     51   \item[Fullscreen] Fullscreen mode is actually a subset of the
     52     floating style. Windows may be toggled to and from
     53     fullscreen mode at will. When fullscreen, windows reside in
     54     the floating layer, above the managed windows. They have no
     55     borders or titlebars, and occupy the full area of the
     56     screen. Other than that, however, they're not special in any
     57     way. Other floating windows may appear above them and the
     58     user can still select, open, and close other windows at
     59     will.
     60 \end{description}
     61 
     62 \subsection{The Filesystem}
     63 
     64 All of \wmii's customization is done via a virtual filesystem.
     65 Since the filesystem is implemented in the standardized \ninep\
     66 protocol, it can be accessed in many ways. \wmii\ provides a
     67 simple command-line client, \wmiir, but many alternatives exist,
     68 including libraries for Python, Perl, Ruby, PHP, and C. It can
     69 even be mounted, either by Linux's 9p.ko kernel module or
     70 indirectly via FUSE.
     71 
     72 The filesystem that \wmii\ provides is “virtual”, which is to
     73 say that it doesn't reside on disk anywhere. In a sense, it's a
     74 figment of \wmii's imagination. Files, when read, represent
     75 \wmii's current configuration or state. When written, they
     76 perform actions, update the UI, etc. For instance, the directory
     77 |/client/| contains a directory for each window that \wmii\
     78 is currently managing. Each of those directories, in turn,
     79 contains files describing the client's properties (its title,
     80 its views\footnote{Views in \wmii\ are akin to workspaces or
     81 virtual desktops in other window managers, but with some subtle
     82 differences.}, its state). Most files can be written to update
     83 the state they describe. For instance,
     84 |/client/sel/ctl| describes the state of the selected
     85 client. If a client is fullscreen, it contains the line:
     86 
     87 \begin{code}
     88   fullscreen on
     89 \end{code}
     90 
     91 \noindent To change this, you'd update the file with the line
     92 % XXX: Line broken at /ctl cmd.
     93 |fullscreen off| or even |fullscreen| |toggle| to toggle
     94 the client's fullscreen state.
     95 
     96 The concept of controlling a program via a filesystem derives
     97 from \plannine, where such interfaces are extensive and well
     98 proven\footnote{The concept has also taken hold on most Unixes
     99 in the form of \texttt{/proc} and \texttt{/sys} virtual
    100 filesystems, but tends to be very kernel-centric. On \plannine,
    101 where the model is more pervasive, there are more virtual
    102 filesystems for user-level applications than for the kernel.}.
    103 The metaphor has shown itself to be quite intuitive to Unix
    104 users, once the shock of a “virtual” filesystem wears off.  The
    105 flexibility of being able to control \wmii\ from myriad
    106 programming languages, including the standard Unix shell and
    107 even from the command line, is well worth the shock.
    108 
    109 \subsection{Views and Tags}
    110 
    111 Like most X11 window managers, \wmii\ provides virtual
    112 workspaces. Unlike other window managers though, \wmii's
    113 workspaces are created and destroyed on demand. Instead of being
    114 sent to a workspace, windows in \wmii\ are tagged with any
    115 number of names. Views are created dynamically from these tags,
    116 and automatically if the user tries to access them.  For
    117 instance, if a window is given the tags ‘foo’ and ‘bar’, the two
    118 views ‘foo’ and ‘bar’ are created, if they don't already exist.
    119 The window is now visible on both of them. Moreover, tags can be
    120 specified as regular expressions. So, a client tagged with {\tt
    121 \verb+/^foo/+} will appear on any view named ‘foo’, ‘foo:bar’,
    122 and so forth. Any time a client is tagged with a matching tag,
    123 or the user opens a matching view, the window is automatically
    124 added to it.
    125 
    126 \subsection{The Bar}
    127 
    128 \wmii\ provides a general purpose information bar at the top or
    129 bottom of the screen. The bar is divided into a left and a right
    130 section. Each section is made up of buttons, with a single
    131 button spanning the gap between the two sides. Buttons can be
    132 individually styled and can hold any text content the user
    133 wishes. By convention, the buttons to the left show view names,
    134 and those to the right display status information.
    135 
    136 \subsection{The Menus}
    137 
    138 \wmii\ includes two simple, external menu programs. The first,
    139 \wimenu, is keyboard-based, and is used to launch programs and
    140 generally prompt the user for input. It provides a list of
    141 completions which are automatically filtered as you type. The
    142 second, \wiIXmenu, is mouse-based, and is generally used to
    143 provide context menus for titlebars and view buttons. Both menus
    144 can be easily launched from shell scripts or the command line,
    145 as well as from more complex scripting languages.
    146 
    147 \subsection{The Keyboard}
    148 
    149 \wmii\ is a very keyboard friendly window manager. Most actions
    150 can be performed without touching the mouse, including
    151 launching, closing, moving, resizing, and selecting programs.
    152 New keybindings of any complexity can easily be added to handle
    153 any missing functionality, or to simplify any repetitive tasks.
    154 
    155 \subsection{The Mouse}
    156 
    157 Despite being highly keyboard-accessible, \wmii\ strives to be
    158 highly mouse accessible as well. Windows can be moved or resized
    159 by dragging their window borders. When combined with a key
    160 press, they can be moved, resized, or raised by dragging any
    161 visible portion of the window. Mouse menus are accessed with a
    162 single click and drag. View buttons in the bar and client
    163 titlebars respond to the mouse wheel; view buttons can be
    164 activated by dragging any draggable object (e.g., a file from a
    165 file manager) over them.
    166