Scwm: An Extensible Constraint-Enabled Window Manager Greg J. Badros Jeffrey Nichols Alan Borning gjb,jwnichls,borning @cs.washington.edu f Dept. of Computer Scienceg and Engineering University of Washington, Box 352350 Seattle, WA 98195-2350, USA Abstract powerful, and satisfying. We desired a platform for researching advanced Using C to implement a highly-interactive applica- window layout paradigms including the use of con- tion also complicates extensibility and customiz- straints. Typical window management systems ability. To add a new feature, the user likely must are written entirely in C or C++, complicating write C code, recompile, relink, and restart the extensibility and programmability. Because no ex- application before changes are finally available for isting window manager was well-suited to our goal, testing and use. This development cycle is es- we developed the Scwm window manager. In pecially problematic for software such as a win- Scwm, only the core window-management primi- dow manager that generally is expected to run for tives are written in C while the rest of the pack- weeks at a time. Additionally, maintaining all the age is implemented in its Guile/Scheme exten- features that any user desires would result in ter- sion language. This architecture, first seen in rible code bloat. Emacs, enables programming substantial new fea- tures in Scheme and provides a solid infrastructure An increasingly popular solution to these prob- for constraint-based window layout research and lems is the use of a scripting language on top of other advanced capabilities such as voice recogni- a core system that defines new domain-specific tion. We have used Scwm to implement an inter- primitives. A prime example of this architecture is face to the Cassowary constraint solving toolkit to Richard Stallman’s GNU Emacs text editor [39]. permit end users to declaratively specify relation- In the twenty years since the introduction of ships among window positions and sizes. The win- Emacs, numerous extensible scripting languages dow manager dynamically maintains those con- have evolved including Tcl [34], Python [22], straints and lets users view and modify them. Perl [41], and Guile [11, 36]. Each of the first Scwm succeeds in providing an excellent imple- three languages was designed from scratch with mentation framework for our research and is prac- scripting in mind. In contrast, Guile—the GNU tical enough that we rely on it everyday. Ubiquitous Intelligent Language for Extension— takes a pre-existing language, Scheme, and adapts it for use as an extension language. 1 Introduction We are exploring constraint-based window layout paradigms and their user interfaces. Because we We desired a platform for researching advanced are most interested in practical use of constraints, window layout paradigms including the use of con- we decided to target the X windows system and straints. Typical window management applica- build a complete window manager for X/11. We tions for the X windows system are written en- chose to use Guile/Scheme as the extension lan- tirely in a low-level systems language such as C guage for our project that we named Scwm—the or C++. Because the X windows libraries have Scheme Constraints Window Manager. The most a native C interface, using C is justified. How- notable feature of Scwm is constraint-based lay- ever, a low-level language is far from ideal when out. Whereas typical window management sys- prototyping implementations of sophisticated win- tems use only direct manipulation [37] of win- dow manager functionality. For our purposes, a dows, Scwm also supports a user-interface for higher-level language is much more appropriate, specifying constraints among windows that it then deal with innumerable quirks of applications. By maintains using our Cassowary Constraint solving basing Scwm on fvwm2, we leveraged those capa- toolkit [1]. Much of the advanced functionality of bilities to ensure that Scwm was at least as well- Scwm is implemented in Scheme, thus exploiting behaved as fvwm2. Our fundamental change to the embedded-extension-language architecture. fvwm2 was to replace its ad-hoc configuration lan- guage with Guile/Scheme [11]. The next section discusses some background is- sues. Section 3 describes the Scwm system in 2.2 Scheme for Extensibility detail and discusses some of the benefits and dif- ficulties that arise in using Guile/Scheme. Sec- Guile [11] is the GNU project’s R4RS-compliant tion 4 describes the constraint-based capabilities Scheme [8] system designed specifically for use as of Scwm. Section 5 mentions related work, and an embedded interpreter. Scheme is a very simple, section 6 discusses future work and concludes. elegant dialect of the long-popular Lisp program- ming language. It is easy to learn and provides exceptionally powerful abstraction capabilities 2 Background including higher-order functions, lexically-scoped closures and a hygienic macro system. Guile Scwm leverages numerous existing technologies extends the standard Scheme language with a to provide its infrastructure and support its ad- module system and numerous system libraries vanced capabilities. wrappers (e.g., POSIX file operations). 2.1 X Windows and fvwm2 2.3 Embedded Constraint Solver A fundamental design decision for the X window- ing system [32] was to permit an arbitrary user- Cassowary is a constraint solving toolkit that in- level application to manage the various applica- cludes support for both arbitrary linear arith- tion windows. This open architecture permits metic equalities and inequalities [1]. We imple- great flexibility in the way windows look and be- mented the Cassowary toolkit in C++, Java, and have. Smalltalk, and created a wrapper of the C++ implementation for Guile/Scheme. Thus, it is X window managers are complex applications. straightforward to use the constraint solver in a Many Xlib library functions wrapping the X broad range of target applications. protocol are specific to the extraordinary needs of window managers. Because our goal is to do in- In addition, the Cassowary toolkit permits numer- teresting research beyond that of modern window ous hooks for extension. Each constraint vari- managers, we used an existing popular window able has an optional attached object, and the con- straint solver can be instructed to invoke a call- manager, fvwm2, as our starting point [12]. In 1997 when the first author began the Scwm back upon changing the value assigned to any variable and also upon completion of the re-solve project with Maciej Stachowiak, fvwm2 was arguably the most used window manager in the phase (i.e., after all variable assignments are com- Scwm X windows community. It supports reasonably pleted). exploits these facilities to isolate sophisticated configuration capabilities via a the impact of the constraint solver on existing code. per-user .fvwm2rc file that is loaded once when fvwm2 starts. To tweak a parameter, end users edit their .fvwm2rc files using an ordinary text editor, save the changes, then restart the window 3 The System manager to activate the change. The fvwm2 configuration language supports a very restricted Scwm is a complex software system that empha- form of functional abstraction, but lacks loops sizes extensibility and customizability to enable and conditionals. sophisticated capabilities to be developed and tested quickly and easily. The window man- Despite these shortcomings, fvwm2 does provide ager embraces the embedded-scripting language a good amount of control over the look of win- architecture first introduced by Emacs (sec- dows and has evolved over the years to meet com- tion 3.1) and it further exploits Guile/Scheme’s plex specifications (e.g., the Interclient Communi- support for dynamically-loadable binary modules cation Conventions Manual, or ICCCM [35]) and (section 3.2). SCWM_PROC( X_property_get, (define*-public (window-class "X-property-get", #&optional (win (get-window))) 2, 1, 0, "Return the class of window WIN." (SCM win, SCM name, SCM consume_p)) (X-property-get win "WM_CLASS")) /** Get X property NAME of window WIN. */ #define FUNC_NAME s_X_property_get { Figure 2: The “window-class” procedure. SCM answer; VALIDARG_WIN_ROOTSYM_OR_NUM_COPY(1,win,w); VALIDARG_STRING_COPY(2,name,aprop); uration language replaced by Guile/Scheme. Like VALIDARG_BOOL_COPY_USE_F(3,consume_p,del); fvwm2, Scwm reads a startup file containing all of ... the commands to initialize the settings of various XGetWindowProperty(...); options. Most fvwm2 commands have reasonably ... answer = ...; straightforward translations to Scwm sentential return answer; expressions. For example, these fvwm2 configura- } tion lines: #undef FUNC_NAME Style "*" ForeColor black Scwm Figure 1: An example primitive. Style "*" BackColor grey76 This extra power and incredible extensibility can HilightColor white navyblue complicate using the window manager. To sim- plify configuration, Scwm permits developers an AddToFunc Raise-and-Stick easy way to declaratively define various options. + "I" Raise Scwm then automatically builds a graphical user- + "I" Stick interface that enables end users to easily manipu- lating those parameters (section 3.3). Key s WT CSM Function Raise-and-Stick Additionally, the use of a scripting language re- are rewritten for Scwm in Guile/Scheme as:1 quires the developer to maintain various software- engineering invariants to avoid hard-to-find bugs. We developed a technique to verify and warn de- (window-style "*" #:fg "black" velopers when the Guile-required coding conven- #:bg "grey76") tions are violated (section 3.4). (set-highlight-foreground! "white") Another challenge was embedding Cassowary in (set-highlight-background! "navyblue") Scwm reasonably non-invasively. To avoid alter- ing all of the functions that access or mutate fields (define* (raise-and-stick of the window structure required exploiting some #&optional (win (get-window))) of the extensibility features built into the con- (raise-window win) straint solving toolkit (section 3.5). (stick win)) The current implementation of Scwm contains (bind-key '(window title) "C-S-M-s" roughly 32,500 non-comment, non-blank lines of raise-and-stick) C code, 800 lines of C++ code, and 25,000 lines of Scheme code.