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