Scwm: An Extensible Constraint-Enabled Window Manager

Greg J. Badros Jeffrey Nichols Alan Borning gjb,jwnichls,borning @cs.washington.edu { Dept. of Computer Science} 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. The Guile/Scheme system is about 44,000 lines of C code and 11,500 lines of Scheme Although the simpler and more regular syntax is code. Finally, the Cassowary constraint solving more convenient for the end user, the greatest ad- toolkit is about 9,500 lines of C++ code in its vantage of using a real programming language in- core, plus about 1,400 lines of C++ code in the stead of a static configuration language stems from Guile wrapper. the ability to extend the set of commands (either by writing C or Scheme code) and to combine those new procedures arbitrarily. 3.1 Basic philosophy 1Because the fvwm2 configuration language is so limited, it is possible to mechanically convert to Scwm commands; Our first version of Scwm was a simple derivative we provide a reasonably-complete automated translator for of its predecessor, fvwm2, with the ad-hoc config- this purpose. Adding a new Scwm primitive is easily done by Implementing the module was also straightfor- writing a new C function that registers itself with ward. After getting a sample program from IBM’s the Guile interpreter. For example, after imple- ViaVoicetm voice recognition engine working, it re- mentinga“X-property-get” primitive in C (fig- quired less than six hours of development effort to ure 1), we can write a new procedure to report wrap the core functionality of the engine with a a window’s class, which is just the value of its Scheme interface. A grammar describes the vari- WM CLASS property (figure 2). Then we can use that ous utterances that Scwm understands and the C window-class procedure interactively by writing: code asynchronously invokes a Scheme procedure when a phrase is recognized. Because those action procedures are written in Scheme, the responses to (bind-key ’all "C-S-M-f" phrases can easily be modified and extended with- (lambda () out even restarting Scwm. (let* ((win (window-with-focus)) (class (window-class win))) 3.3 Graphical configuration (if (string=? class "Emacs") (resize-window 500 700 win) A great example of the extensibility that Guile (resize-window 400 300 win))))) provides Scwm is the preferences system for graphical customization. Novice Scwm users are The above expressions, when evaluated in Scwm’s unlikely to want to write Scheme code to configure interpreter, will make the user’s “Control + the basic settings of their window manager, such Shift + Meta + f” keystroke resize the window as the background color of the currently-active to either 500 by 700 pixels if the currently-focused window’s titlebar. A graphical user interface is window is an Emacs application window, or 400 necessary to manage these settings, but there are by 300 pixels otherwise. potentially a huge number of configurable param- eters. Undisciplined maintenance of a user inter- The advantages of Scwm’s extensible architec- face for those options would be tedious and error- ture are even more recognizable in the presence prone. of independently-developed Guile extensions that are then accessible to the window manager. Via Fortunately, Scwm can leverage its Scheme standard Guile modules, Scwm can read and parse extension language to ease these difficulties. web pages, download files via ftp, do regular ex- The defoption module provides a macro pression matching, and much more. define-scwm-option that permits declarative specification of the conceptual and functional 3.2 Binary Modules attributes of a configuration option.2 To expose a graphical interface to the *highlight- Because each user only needs a subset of the full background* configuration variable, the Scwm functionality that Scwm provides, it is important developer need simply write: that users only pay for (in terms of size of the pro- cess image) the features they require. Guile, un- like Emacs Lisp, enables creation of dynamically- (define-scwm-option loadable binary modules to define new primitives. *highlight-background* "navy" Without this feature, all primitives would need to "The bg color for focused window." be defined in the Scwm core, thus complicating #:type ’color thesourcecodeandincreasingthesizeofthere- #:group ’face sulting monolithic system. #:setter (lambda (v) (set-highlight-background! v)) #:getter (lambda () (highlight-background))) The voice recognition module based on IBM’s ViaVoicetm software is an excellent example of the benefits of dynamically-loaded extensions. Some This code states that *highlight-background* users do not to use that feature—perhaps because is an end user configurable variable that will con- the library is not available on their platform or tain a value that is a color. It also specifies that maybe because they have no audio input device. the variable can be grouped with other variables Those users will never have the module’s code 2 loaded. Additionally, if ViaVoice does not exist Recent versions of Emacs [39] provide a similar feature in their “customize” package. The layout of their user- at compile time, the voice recognition module will interfaces is simpler, though, as no attempt is made to not even be built. create a fully graphical interface. into a face category. Finally, setter and getter the documentation strings for the various avail- procedures are specified to teach Scwm how to able procedures, hooks, and variables. Addition- alter and retrieve the value. ally, that script verifies numerous of the invari- ants that the C language is not expressive enough The preferences module then accumulates all of to enforce and reports violations to the developer. these specifications and dynamically generates the Many bugs are eliminated via this static technique user interface shown in figure 3.3 This modular before they are ever encountered at run-time. approach also enforces the separation of the vi- sual appearance from the desired functionality—a 3.5 Connecting to Cassowary visually-distinct notebook-style interface with the same functionality is also available. The most important module for our research on advanced window layout paradigms is the wrap- 3.4 Verifying Coding Conventions per of the Cassowary constraint solving toolkit. To connect the constraint solver with the window Much of the Scwm C source code describes im- manager, the variables known to the solver must plementations of new Guile primitives. That code relate to aspects of the window layout. Each appli- must adhere to numerous conventions required by cation window object contains four constrainable the Guile library. These conventions generally lie variables: x, y—the offsets of the window from the outside the realm of what the C programming lan- top-left corner of the virtual desktop); and width, guage can express directly and often involve exten- height—the dimensions of the window frame in sive use of the C preprocessor, cpp. pixels. When Cassowary finds a new solution to the set of constraints, it invokes a hook for Consider the X property get function from fig- each constraint variable whose value it changes, ure 1. The SCWM PROC, FUNC NAME,andVALIDARG * and invokes another hook after all changes have expressions are all macro invocations that man- been made. For Scwm, the constraint-variable- age some of the complexities in consistently fol- changed hook adds the window that embeds that lowing Guile conventions for defining a new proce- constraint variable to its “dirty set,” and the sec- dure and appropriately signalling arguments that ond hook repositions and resizes all of the windows are of the wrong type. Although these macros in the dirty set. are invaluable, there are numerous dependencies throughout the source code that the C compiler In each window object, the constrainable vari- can not enforce. ables that correspond to the window’s position and size actually mirror the ordinary integer vari- For example, figure 1’s VALIDARG STRING COPY ables that the rest of the application uses. The macro invocation has three arguments: the first above-described hooks copy the new values as- two arguments are an index to a formal argument signed to the constrainable variables into the or- and the name of that argument. Suppose the dinary variables. This technique avoids modifying index is incorrectly given as 1 instead of 2.Ifsuch the vast majority of the code that manipulates a mis-match occurs, the user of the primitive will and manages windows. Bjorn Freeman-Benson encounter the misleading error message Wrong discusses these issues in greater detail [10]. type argument in position 1: "WM CLASS" when they dynamically pass a non-string as the To make it easy to express constraints among second argument to the primitive. Violating windows, the constraint variables embedded in other similar conventions can have more severe each window are available to Scheme code via the consequences including corruption of the Scheme accessor primitives window-clv- xl,xr,yt,yb, heap. To improve reliability, it is imperative that width,height , where, for example,{ -xl names these source-code invariants are checked. the x coordinate} of the left side of the window and -yb abbreviates the y coordinate of the bottom Our solution is to augment our documentation ex- of the window.4 Thus, to keep the tops of two traction tool to also check these conventions stati- window objects aligned, we can use: cally. We regularly run a 1200 line Perl script over the entire Scwm source code (both C and Scheme) to create a reference manual and a database of (cl-add-constraint solver (make-cl-constraint 3The user interface is written in guile-gtk, a Guile wrap- per of the GTk+ widget toolkit [17] that integrates seam- 4For each window, explicit constraints xr = x + width lessly with Scwm. and yb = y + height are added automatically by Scwm. Figure 3: The automatically-generated options dialog.

(window-clv-yt win1) = tively, the user can first highlight the windows to (window-clv-yt win2))) be constrained and then click the appropriate but- ton. Icons and tooltips with descriptive text assist the user in understanding what each constraint Although these primitive constraint-creation con- does. We consulted with a graphic artist on the structs are sufficient for specifying desired rela- design of our icons in an effort to make them in- tionships, end-users need a higher-level interface tuitive and attractive. Preliminary user studies to make use of the solver in their daily activities. have demonstrated that users can guess the repre- The next section describes the graphical interface sented relationship reasonably well from the icons we built on top of these primitives. even without the supporting tooltip text.

We provide the following constraint classes in our 4 Constraints for Layout system. Most interesting relationships are either present or can be created by combining classes in Ordinary window managers permit only direct- the list. manipulation as a means of laying out their windows. Although this technique is useful, Constant Height/Width Sum Keep the total a constraint-based approach provides greater of the height/width of two windows con- dynamicism and expressiveness. In Scwm,we stant. use the Cassowary constraint solving toolkit described in sections 2.3 and 3.5. On top of Horizontal/Vertical Separation Keep one the primitive equation-solving capabilities of window always to the left of or above Cassowary, Scwm adds a graphical user interface another. that employs an object-oriented design. We specify numerous constraint classes representing Strict Relative Position Maintain the relative kinds of constraint relationships, and zero or more positions of two windows. instances of each class are added to the system for Vertical/Horizontal Maximum Size Keep maintaining relationships among actual windows. the height/width of a window below a The interface allows users to create constraint threshold. objects, to manage constraint instances, and to create new constraint classes from existing classes Vertical/Horizontal Minimum Size Keep by demonstration. the height/width of a window above a threshold. 4.1 Applying Constraints Vertical/Horizontal Relative Size Keep the change in heights/widths of two windows Applying constraints to windows is done using a constant (i.e., resize them by the same toolbar. Each constraint class in the system is rep- amount, together). resented by a button on the toolbar (figure 4). The user applies a constraint by clicking a button, then Vertical/Horizontal Alignment Align the selecting the windows to be constrained. Alterna- edge or center of one window along a Figure 4: Our constraint toolbar. The text describes the constraint classes in the same order as they are laid out in the toolbar (from left to right).

vertical/horizontal line with the edge or other windows. Our constraint investigation in- center of another window. terface allows for all of these kinds of interactions.

Anchor Keep a window in place. The primary means of inspecting constraints is through visual representations superimposed di- rectly on the windows that the relationship in- Some of these constraint types can constrain win- volves (figure 6). When the mouse pointer hovers dows in several different ways. For example, the over a constraint in the investigator, the repre- “Vertical Alignment” constraint can align the left sentation of that constraint is drawn. This hint edge of one window with the right edge of another makes it easy for the user to make the correct as- or the right edge of one window with the middle sociations between windows and constraints. Each of another. Users specify the parameters of the re- constraint class also defines its own visual repre- lationship by using window “nonants” (figure 5). sentation, which in most cases closely matches the The nonant that the user clicks in dictates the part icon in the toolbar. of the window that the constraint relates. For example, if the user selects the “Vertical Align- The constraint investigation window also allows ment” constraint and chooses the first window by the user to enable and disable one or all con- clicking in any of the east nonants and the second straints via a checkbox and to remove a con- window by clicking on its left edge, the resulting straints via a delete button. The constraint inves- constraint will hold the right edge of the first win- tigator can be kept on-screen at all times and dy- dow in line with the left edge of the second. This namically updates as constraints are applied and technique makes some constraint classes, such as removed. Together with the visual representation alignment, more generally useful. It also decreases system, the investigation window makes it easy to the number of buttons on the toolbar, which could manipulate constraints. otherwise become unwieldy with many narrowly- applicable constraint classes. Enabling or disabling constraints can result in global rearrangements of windows and large NW NNE changes in position. To make these discontinu- 013 ities less confusing, we animate windows fluidly from their old positions and sizes to their new WCE 345 configuration. The animations borrow features from the Self programming environment that SWSSE mimic cartoon-style animation [6]. 678 4.3 Constraint abstractions Figure 5: The nine nonants of a window. A problem with the interface as described thus far 4.2 Managing Constraints is that the basic constraint classes, such as “Verti- cal Alignment” and “Horizontal Separation,” are Once a constraint is applied, the user still needs not always sufficient to convey a user’s intention to be able to manage it. Users may wish to dis- fully. Our own use showed that often one needs able the constraint temporarily or remove it en- to combine several constraints to obtain the de- tirely. They may also encounter an odd behavior sired behavior. A good example of this situation while they are moving or resizing a window and is tiling (figure 7), where two or more windows want to discover which constraint(s) caused the are aligned next to each other such that they ap- unexpected result. They may simply be curious pear to become a window unit of their own. A to know what constraints are applied to a given tiling configuration for two windows can take from window and how that window will interact with three to five constraints to implement. Adding the Figure 6: Visual representation of constraints. XTerm A is constrained to be to the left of XTerm B, and above XTerm C. Additionally, XTerm C is required to have a minimum width, and the XEmacs window’s southeast corner is anchored at its current location. The constraint investigator that allows users to manage the constraints instances appears in the bottom left of the screen shot. constraints can become tedious when tiling many windows, or when repeatedly tiling and untiling two windows. Certainly a “tiled windows” con- straint class could be hard-coded into the system, but that just postpones the problem—some means of abstracting relationships must be provided to the end user.

Our solution to this problem was to create con- straint “compositions.” A composition is created by a simple programming by demonstration tech- nique. We record the user applying a constraint arrangement to some windows in their workspace. The constraints used and the relationships created among the windows are saved into a new con- straint class object. This class object appears in Figure 7: Four windows tiled together. Unlike the toolbar like all other constraint classes. Click- tiled-only window managers, Scwm permits users ing the button in the toolbar will prompt the user to simply tile a subset of their windows; other win- to select a number of windows equal to that used dows could overlap arbitrarily. in the recording. The constraints will then be ap- plied in the same order as before. Compositions Language [30]. It supported programmability, allow users to accumulate a collection of often- and some of its packages, such as directional focus used constraint configurations that can then be changing, inspired similar modules in Scwm. easily applied. Sawmill [19] is a new window manager with an architecture similar to gwm and Scwm. Like 4.4 Inferring Constraints gwm, it embeds its own unique dialect of Lisp (called “rep”). Both embrace the extensibility Our toolbar-based user interface allows flexible re- language architecture and provide low level lationships to be specified, but many common user primitives, then implement other features in their desires reflect very simple constraints. For exam- extension language. However, the embedded Lisp ple, users may place a window directly adjacent dialects used by gwm and Sawmill both suffer to another window and want them to stay to- from the lack of lexical closures that Scheme gether. Some windowing systems provide a basic provides Scwm. Neither gwm nor Sawmill has “snapping” behaviour that recognizes when a user any constraint capabilities, though the hooks they puts a window nearly exactly adjacent to another provide can permit procedural implementations to window and then adjusts the window coordinates approximate some of the simpler constraint-based slightly to have them snap together precisely. behaviours that Scwm implements.

One useful extension to basic snapping is “aug- Various other scripting languages exist. As men- mented snapping” [14]. Using this technique, the tioned previously, GNU Emacs and its Emacs Lisp user has the option of transforming a snapped-to is most similar to Scwm in philosophy, prompting relationship to a persistent constraint that is then Scwm to be dubbed “the Emacs of Window Man- maintained during subsequent manipulations. agers” by its users. The earliest popular general- Scwm supports this augmented snapping via a purpose scripting languages is Tcl, the tool com- simple extension to its basic snapping module. mand language [34]. John Ousterhout, Tcl’s au- When a snap is performed, instead of simply thor, makes a compelling case for the advantages moving the window, the appropriate constraint of scripting [33]. Tcl is an incredibly simple but object is created and added to the system. Such under-powered language. Subsequent similar lan- inferred constraints can be manipulated via the guages include Python [22] and Perl [41]; both are constraint investigator described earlier. They far more feature-full languages than Tcl, but all also can be removed by simply “ripping-apart” three are more commonly used for scripting where the windows by holding down the Meta modifier the main control resides with the language. Scwm key while using direct manipulation to move them and Emacs both exploit their languages for em- apart. bedding and invoke scripting code in response to events dispatched by C code.

5 Related Work There are also several other Scheme-based ex- tension languages. Elk [9] is an early Scheme There is considerable early work on windowing intended as an extension language but is no systems [15, 16, 26, 25, 27, 23]. Many of these longer well supported. siod (Scheme In One projects addressed lower-level concerns that a con- Defun) [38] is an especially compact implemen- temporary X/11 window manager can ignore. An tation of Scheme that in return compromises issue that does remain is tiled vs. overlapping win- completeness and standards-compliance; it is dows. Scwm, like nearly all windowing inter- embedded in the popular gimp (GNU Image Ma- faces of the 1990s, chooses overlapping windows nipulation Program) application [13] to support for their generality and flexibility. However, un- user-programmable transformations on images. like other systems, Scwm’s constraint solver can permit arbitrary sets of windows to be maintained Numerous other application domains have used in a tiled format of a given size. constraint solvers. Early work includes the draw- ing tool Sketchpad [40] and the simulation labora- Although there are literally dozens of modern tory ThingLab [5]. Many other drawing programs window managers in common use on the X have embedded constraint solvers over the years windowing platform, only two (besides fvwm2) are including Juno [31], Juno-2 [21], Unidraw [20], and especially related to Scwm. gwm, the Generic Penguin [7]. Unidraw and Penguin both leverage Window Manager, embeds a quirky dialect of QOCA, a constraint solver that (like Cassowary) Lisp called “wool” for Window Object Oriented is able to maintain arbitrary linear arithmetic con- the size of the executable, it will also substan- straints [24]. Scwm includes more than just con- tially reduce startup delays. Fortunately, after straints in its support for intelligent window lay- startup, Scwm’s performance is indistinguishable out; another paper describes some of its other lay- from other window managers that are written en- out capabilities [3]. tirely in C.

Web browser layout presents challenges similar to Another rich area for future work involves our con- window layout. Our “Constraint Cascading Style straint interface. Currently, we only supports con- Sheets” work also embeds Cassowary and exposes straints among windows. It seems useful to per- a declarative specification language to web au- mit the addition of “guide-line” and “guide-point” thors for describing page layout [2]. Widget layout elements and allow windows to be constrained rel- in user interfaces is yet another two-dimensional ative to them. These could, for example, be used layout problem. Amulet [29] and the earlier Gar- to ensure that a window stays in the current view- net [28] both provided constraint solvers based port, or stays in a specific region of the display. It on simple local propagation techniques. These would also be intriguing to investigate the pos- solvers suffer from an inability to handle inequal- sibility of ghost-frame objects that are controlled ities and simultaneous equations, which unfortu- exclusively by Scwm. These window frames could nately arise all too often in the natural declarative then hold real application windows by dragging specification of layout desires. them into the frame. This feature would permit hierarchically organizing windows, while still al- lowing full access to the constraint solver for non- hierarchical relationships. 6 Conclusions and Future Work We are also considering extending our voice-based One of the most useful aspects of this research interface to permit specifying constraints. In has been the continuous feedback from our end Scwm, a user can center a window simply by users throughout the development of Scwm.Since saying aloud “Center current window.” The 1997, we have made the latest version of Scwm voice recognition interface to window layout (along with all of its source code) available on the and control encourages the user to express Internet, and have actively solicited feedback on higher level intention: it is far more awkward our support mailing lists. Many of the high-level to say “move window to 379, 522” than it is layout features were developed in response to real- to say “move window next to Emacs.” In this world frustrations and annoyances experienced ei- way, the voice interface usefully contrasts with ther by the authors or by our user community. direct manipulation where exact coordinates Although cultivating that community has taken naturally result from the interaction technique. time and effort, we feel that the benefits from user Additionally, voice-based interactions may prove feedback outweigh the costs. especially valuable for disabled users for whom direct manipulation is difficult. Two years ago when we first began the Scwm project, fvwm2 was a good choice as a starting Discerning a user’s true intention is an interest- point for a new window manager. Since then, ing complexity of the declarative specification of though, several other window managers have ma- our current constraints interface. Consider a user tured and are far more feature-full than fvwm2. who is manipulating three windows, A, B,andC. Most notably, Enlightenment [18] and Window- Suppose the user constrains A to be to the left of Maker [42] are popular powerful window managers B,andBto the left of C. Now suppose the ap- that might prove useful as a starting point for a plication displaying in window B terminates, thus new version of Scwm. removing that window. Should window A still be constrained to be to the left of window C?In Perhaps the most significant implementation issue other words, should the transitive constraint that for Scwm is its startup time of nearly 20 seconds was implicit through window B be preserved? The on a Pentium III 450 class machine. Loading the answer depends on the user’s underlying desire. nearly 20,000 lines of Scheme code at every restart Providing higher-level abstractions for commonly- is costly, and wasteful. Ideally, we could add an desired situations may alleviate this ambiguity. Emacs-like “unexecing” capability to dump the For example, if the user had pressed a button to state of a Scwm process that has all of the ba- keep three windows horizontally non-overlapping sic modules loaded. Although this will increase in a row, it is clear that window B’s disappearance versity, March 1979. A revised version is pub- should not remove the constraint that window A lished as Xerox Palo Alto Research Center Report remain to the left of C. SSL-79-3 (July 1979). [6] B.-W. Chang and D. Ungar. Animation: From Finally, we are especially interested in combining cartoons to the user interface. In Proceedings our work with constraints and the web [2] with of the 1993 ACM Conference on User Interface this work on window layout. Web, window, and Software and Technology, pages 45–55, Atlanta, widget layout are all fundamentally related and Georgia, November 1993. User Interface Software their similarities should ideally be factored out and Technology. into a unifying framework so that advances made [7] S. S. Chok and K. Marriott. Automatic construc- in any area benefit all kinds of flexible, dynamic tion of intelligent diagram editors. In Proceed- two-dimensional layout. ings of UIST 1998, San Francisco, CA, November 1998. [8] W. Clinger and J. Rees. Revised 4 Report on the Acknowledgments Algorithmic Language Scheme, November 1991. [9] Elk—the extension language kit. Web page, We thank Maciej Stachowiak, Sam Steingold, 1999. http://www-rn.informatik.uni-bremen.de/ Robert Bihlmeyer, and Todd Larason for their software/elk. contributions to the Scwm project. This research [10] B. Freeman-Benson. Converting an existing user has been funded in part by both a National Sci- interface to use constraints. In Proceedings of ence Foundation Graduate Research Fellowship the ACM SIGGRAPH Symposium on User In- and the University of Washington Computer terface Software and Technology, pages 207–215, Science and Engineering Wilma Bradley fellow- Atlanta, Georgia, November 1993. ship for Greg Badros, and in part by NSF Grant [11] FSF. Guile—The GNU Ubiquitous Intelligent No. IIS-9975990. Language for Extension. Web page, 1999. http:// www.gnu.org/software/guile/guile.html. Availability [12] fvwm—the f? virtual window manager. Web page, 1999. http://www.fvwm.org. Scwm is freely available; see http://scwm.mit.edu. [13] Gimp—GNU image manipulation program. Web page, 1999. http://www.gimp.org. The Cassowary constraint solving toolkit is avail- [14] M. Gleicher. Integrating constraints and direct able free for research purposes; see http://www.cs. manipulation. In Proceeding 1992 Symposium on washington.edu/research/constraints/cassowary. Interactive 3D, pages 171–174, 1992. [15] J. Gosling. SunDew – a distributed and extensi- ble window system. In Methodology of Window References Management, chapter 5, pages 47–57. Springer Verlag, Heidelberg, Germany, 1986. [1] G. J. Badros and A. Borning. The Cassowary [16] J. Gosling and D. Rosenthal. A window manager linear arithmetic constraint solving algorithm: for bitmapped displays and unix. In Methodology Interface and implementation. Technical Re- of Window Management, chapter 13, pages 115– port UW-CSE-98-06-04, University of Washing- 128. Springer Verlag, Heidelberg, Germany, 1986. ton, Seattle, Washington, June 1998. [17] GTk+—the GIMP toolkit. Web page, 1999. [2] G. J. Badros, A. Borning, K. Marriott, and http://www.gtk.org. P. Stuckey. Constraint cascading style sheets for the web. In Proceedings of the 1999 ACM Confer- [18] C. Haitzler. Enlightenment. Web page, 1999. ence on User Interface Software and Technology, http://www.enlightenment.org. November 1999. [19] J. Harper. Sawmill. Web page, 1999. http:// [3] G. J. Badros, J. Nichols, and A. Borning. www.dcs.warwick.ac.uk/ john/sw/sawmill. Scwm —the Scheme Constraints Window Man- [20] R. Helm, T. Huynh, K. Marriott, and J. Vlissides. ager. In Proceedings of the AAAI Spring Sympo- An Object-Oriented Architecture for Constraint- sium on Smart Graphics, March 2000. To appear. Based Graphical Editing, chapter 14, pages 217– [4] G. J. Badros and M. Stachowiak. Scwm—The 238. Springer, 1995. Scheme Constraints Window Manager. Web [21] A. Heydon and G. Nelson. The Juno-2 constraint- page, 1999. http://scwm.mit.edu/scwm/. based drawing editor. Technical Report 131a, [5] A. Borning. ThingLab—A Constraint-Oriented Digital Systems Research Center, Palo Alto, Cal- Simulation Laboratory. PhD thesis, Stanford Uni- ifornia, December 1994. [22] M. Lutz. Programming Python. O’Reilly & As- [37] B. Schneiderman. Direct manipulation: A step sociates, Inc., Sebastopol, California, 1996. beyond programming languages. IEEE Com- [23] M. S. Manasse and G. Nelson. Trestle Reference puter, 16(8):57–69, August 1983. Manual. Digital Systems Research Center, [38] SIOD—scheme in one defun. Web page, 1999. December 1991. http://gatekeeper.dec.com/ http://people.delphi.com/gjc/siod.html. pub/DEC/SRC/research-reports/abstracts/src- [39] R. M. Stallman. EMACS: The extensible, rr-068.html. customizable display editor. Technical Re- [24] K. Marriott, S. S. Chok, and A. Finlay. A tableau port 519a, Massachusetts Institute of Technol- based constraint solving toolkit for interactive ogy Artificial Intelligence Laboratory, March graphical applications. In International Confer- 1981. http://www.gnu.org/software/emacs/ ence on Principles and Practice of Constraint emacs-paper.html. Programming, 1998. [40] I. Sutherland. Sketchpad: A Man-Machine [25] B. Myers. Issues in window management design Graphical Communication System. PhD thesis, and implementation. In Methodology of Window Department of Electrical Engineering, MIT, Jan- Management, chapter 6, pages 59–71. Springer uary 1963. Verlag, Heidelberg, Germany, 1986. [41] L. Wall, T. Christiansen, and R. L. Schwartz. [26] B. A. Myers. The user interface for Sap- Programming Perl. O’Reilly & Associates, Inc., phire. IEEE Computer Graphics and Applica- Sebastopol, California, 1996. tions, 4(12):13–23, December 1984. [42] WindowMaker. Web page, 1999. http://www. [27] B. A. Myers. A taxonomy of user interfaces for windowmaker.org. window managers. IEEE Computer Graphics and Applications, 8(5):65–84, September 1988. [28] B. A. Myers, D. Giuse, R. B. Dannenberg, B. Vander Zanden, D. S. Kosbie, P. Marchal, E. Pervin, A. Mickish, and J. A. Kolojejchick. The Garnet toolkit reference manuals: Support for highly-interactive graphical user interfaces in Lisp. Technical Report CMU-CS-90-117, Com- puter Science Dept, Carnegie Mellon University, March 1990. [29] B. A. Myers, R. G. McDaniel, R. C. Miller, A. S. Ferrency, A. Faulring, B. D. Kyle, A. Mickish, A. Klimovitski, and P. Doane. The Amulet envi- ronment: New models for effective user interface software development. IEEE Transactions on Software Engineering, 23(6):347–365, June 1997. [30] C. Nahaboo. GWM—the generic window man- ager. Web page, 1995. http://www.inria.fr/ koala/gwm. [31] G. Nelson. Juno, a constraint-based graphics sys- tem. In Proceedings of SIGGRAPH 1985,San Francisco, July 1985. [32] A. Nye. Xlib Programming Manual. O’Reilly & Associates, Inc., Sebastopol, California, 1992. [33] J. Ousterhout. Scripting: Higher level program- ming for the 21st century. IEEE Computer, March 1998. [34] J. K. Ousterhout. Tcl and the Tk Toolkit. Addi- son-Wesley, Reading, Massachusetts, 1994. [35] D. Rosenthal. Inter-client Communications Con- vention Manual, version 2.0 edition, 1994. http:// www.talisman.org/icccm. [36] P. H. Salus, editor. Functional and Logic Pro- gramming Languages, volume 4 of Handbook of Programming Languages, chapter 4. MacMillan Technical Publishin, Indianapolis, Indiana, 1998.