Iw3m Window manager 2021-22

Chapter 1
INTRODUCTION
Windowing systems and window managers alike have assumed crucial roles in guiding the look and
feel of graphical user interfaces. In fact, without them, the concept of a graphical user interface would
not even exist. The windowing system allows for the drawing of graphical primitives to the screen
and creates the notion of windows. Windows are presented on screen, and convey important
information from applications to the user, but how are they to be manipulated? The windowing
system merely provides drawing capabilities and does not in itself allow for the resizing or moving of
windows, or other forms of interaction for that matter. The window manager, a different subset of the
desktop environment, provides this functionality. The window manager interacts with the windowing
system in such a way as to allow the user to be in complete control of the windows and their contents.
Window managers come in many different shapes and forms. Some only enable users to move and
resize windows, whereas others have predefined layouts along which windows can be arranged. In
general, we speak of three types: stacking, tiling, and compositing window managers. Stacking
window managers are the traditional and most widely used type, as they do not impose any
constraints on the user’s interaction with windows, and hence allow them to be moved around and
resized freely. Tiling window managers organize windows into (mutually non-overlapping) partitions
of the screen and often allow the user to alternately activate predefined arrangement schemes.
Compositing window managers often called compositors, perform additional procession of the
windows’ buffers, possibly applying 2D or 3D (animated) effects to them. These systems usually do
not empower the user to replace one or another and as such offer a fixed set of features. Most of the
more popular systems employ stacking window management functionality due to their ease of use.
Tiling functionality is seen as more advanced and requires a user to anticipate an arrangement that
best suits their current workflow. The i3 Window System is the most widely used non-commercial
windowing system. It does not mandate a particular kind of window manager to be running and
thereby allows its users to swap out the window manager if they see fit, facilitating customizability.
To make such customizability possible, the X Window System does not define policy, only
mechanism. To ensure that applications can work well together and can communicate with the
window manager, several standard protocols were designed to define a layer of policy atop the i3
Window System’s mechanism. The two most widely implemented protocols are the Inter-Client
Communication Conventions Manual (ICCCM) and the Extended Window Manager Hints (EWMH).
The development of an i3wm window manager is no small task. To aid in the development process,
an Agile software development methodology can be applied. These two techniques have together
been used to design an Agile methodology geared towards one-person teams called Personal Extreme
Programming. In this thesis, we aim to answer several questions. How do modern top-level window
managers allow for the displaying and positioning of, and user interaction with programs’ graphical
components? What are a window manager’s rights and responsibilities? What is the i3wm Window
System, and how is a policy defined on top of it? What does a window manager in i3wm look like,
and are there alternatives to i3? As we shall see, all of the aforementioned come together nicely as we
discuss knew, an implementation of an ICCCM and EWMH compliant reparenting, tiling i3 window
manager, all the while applying the Personal Extreme Programming methodology. In particular, we
aim to show what a modern tiling window manager .

Dept of CS&E 1 GCE Ramanagaram

Iw3m Window manager 2021-22

Chapter 2
Motivation
The primary aim of this thesis is to offer a unified view of the current state of window management
research, both academic and non-academic, and to present a window manager that combines the best
of these ideas with extensions to them. Academic window management research has largely ignored
the improvements made by research outside academia, which in turn results in window managers or
similar utilities that exist inside systems that only make a single improvement on the state-of-the-art,
or on research systems that may present numerous improvements, but at the cost of compatibility
with popularly-used programs. Examples like WinCuts or Laukkanen’s window manager are made
for Windows, and while they make notable improvements on it, they are otherwise restricted by the
fundamental simplicity of the Windows window manager and have not been made easily available for
the public consumption. Similarly, research systems such as Stack & Tile, Rio on Plan 9, or ETH
Zürich’s A2, while presenting many novel features, are restricted by their sole availability on obscure
operating systems in that they cannot be used by the majority of users who use more complex
applications which do not have a port. None of the three operating systems just mentioned having a
web browser that works with the majority of modern websites, for example. While these are complete
systems and “power users” could, if desired, use them as a primary system, the lack of widespread
support limits the effects of the ideas presented in these systems, despite the portability of the ideas
across window display systems. Conversely, window managers available for public use, whether
commercially or freely available, have failed to incorporate many of the more advanced features
provided by academic window managers. The default window managers available on Microsoft
Windows and Mac OS only offer a basic array of window management utilities and are overall
considerably behind free offerings. This has primarily taken place on i3, which has over 200 window
managers have written with the i3wm protocol. These window managers have presented many
window management interactions and related software architecture advances that have not seen an
intensive study in academic research. However, despite the improvements they have made,
development has almost entirely been performed in complete separation from academic research. Of
the few visible interactions between i3-based window managers and academic research are i3wm’s
development out of Rob Pike’s research that cumulated into 8½ and Rio, and the partial inspiration of
Stack & Tile from Ion. Owing to the improvements they have offered against the state-of-the-art in
academic research and to the lack of an academic review of window managers built on i3wm, part of
this thesis has been devoted to providing a survey of these window managers. The goal of this survey
is to examine the different families of window managers based on the lineage of their code and ideas
and to examine novel features that are offered by more advanced window managers. While some
catalogs have been made of i3wm window managers, these focus more so on the raw set of features
provided by these window managers and their installation and use on a GNU/Linux-based system.
Instead, the window management capabilities and user-interface elements provided by these window
managers will be examined in the survey presented in this thesis. Furthermore, we look to examine
the current landscape of non-i3-based window managers to assess ideas presented on less accessible,
but still publicly-available, window managers. The culmination of this research lies in a new window
manager described in this paper, which was written to bridge the gap between academic and
non-academic window manager research and to extend the state-of-the-art with a few new features.

Dept of CS&E 2 GCE Ramanagaram

Iw3m Window manager 2021-22

Chapter 3

Window Managers
A window manager is not necessarily needed to run X, but it is usually used in combination with X to
facilitate some things. The window manager’s job is to take care of the placement of windows, to
provide the user with some mechanisms to change the position/size of windows, and to communicate
with clients to a certain extent (for example handle fullscreen requests of clients such as MPlayer).

There are no different contexts in which X11 clients run, so a window manager is just another client,
like all other X11 applications. However, it handles some events which normal clients usually don’t
handle.

In the case of i3, the tasks (and order of them) are the following:

1. Grab the key bindings (events will be sent upon keypress/key release)
2. Iterate through all existing windows (if the window manager is not started as the first client of
i3wm) and manage them (reparent them, create window decorations, etc.)
3. When new windows are created, manage them
4. Handle the client’s _WM_STATE property, but only _WM_STATE_FULLSCREEN and
_NET_WM_STATE_DEMANDS_ATTENTION
5. Handle the client’s WM_NAME property
6. Handle the client’s size hints to display them proportionally
7. Handle the client’s urgency hint
8. Handle enter notifications (focus follows mouse)
9. Handle button (as in mouse buttons) presses for focus/raise on click
10. Handle expose events to re-draw own windows such as decorations
11. React to the user’s commands: Change focus, Move windows, Switch workspaces, Change
the layout mode of a container (default/stacking/tabbed), start a new application, restart the
window manager

In the following chapters, each of these tasks and their implementation details will be discussed.

3.1. Tiling window managers

Traditionally, there are two approaches to managing windows: The most common one nowadays is
stacking (or floating, using i3’s terminology), which means the user can freely move/resize the
windows, potentially overlapping them. The other approach is called tiling, which means that the
window manager distributes windows to use as much space as possible while not overlapping each
other.

The idea behind tiling is that you should not need to waste your time moving/resizing windows while
you usually want to get some work done. After all, most users sooner or later tend to layout their
windows in a way that corresponds to tiling or stacking mode in i3. Therefore, why not let i3 do this
for you? Certainly, it’s faster than you could ever do it.

Dept of CS&E 3 GCE Ramanagaram

Iw3m Window manager 2021-22

The problem with most tiling window managers is that they are too inflexible. In my opinion, a
window manager is just another tool, and similar to vim which can edit all kinds of text files (like
source code, HTML, …) and is not limited to a specific file type, a window manager should not limit
itself to a certain layout (like dwm, awesome, …) but provide mechanisms for you to easily create the
layout you need at the moment.

3.2. The layout tree

The data structure which i3 uses to keep track of your windows is a tree. Every node in the tree is a
container (type Con). Some containers represent actual windows (every container with a window !=
NULL), some represent split containers and a few have special purposes: they represent workspaces,
outputs (like VGA1, LVDS1, …), or the X11 root window.

So, when you open a terminal and immediately open another one, they reside in the same split
container, which uses the default layout. In the case of an empty workspace, the split container we are
talking about is the workspace.

To get an impression of how different layouts are represented, just play around and look at the data
structures — they are exposed as a JSON hash. See https://i3wm.org/docs/ipc.html#_tree_reply for
documentation on that and an example.

3.3. Overview

The i3wm Window System has been discussed in great detail elsewhere, so here we merely give a
brief overview of the architecture, libraries, and methodologies used in programming window
managers with the i3 protocol. The i3wm Window System is written in a fully network-transparent
manner, using the i3 server that communicates directly with the computer’s graphics card to draw
graphics to the screen and with any I/O devices for user interaction. Furthermore, it holds its own
state about currently open windows and their corresponding information. The i3 protocol is then used
to communicate with the i3wm server by client programs, most often window managers, which send
commands and receive information from the i3wm server regarding the state of the system.
Information received from the i3wm server can include the display geometry, information about
currently open windows, and events received from I/O devices. As the predominant language for
system-side development on Linux, C is the most frequently used language in i3 development,
closely followed by C++, but as it is merely a protocol, other languages have found use. The oldest,
and still most-used client-side library for i3 is Xlib. It allows for full communication with the i3wm
server over a socket and can be used to interface with the i3wm server using C or C++. Bindings also
exist for other languages, including Python, Common Lisp, Go, and JavaScript. A newer library, the
i3wm protocol C-language Binding (XCB), has gained popularity as 8X-based programs seek to
modernize their code. XCB is much lower-level than Xlib and only consists of asynchronous calls to
the i3 server, whereas Xlib contains both synchronous and asynchronous calls. It is written using an
XML protocol specification, which is then translated by a parser into code in a particular language.
Parsers exist for C, Python, Perl, and Emacs Lisp. Window managers use these libraries to move and
resize windows, as well as controlling which windows appear on the screen, which can be applied to

Dept of CS&E 4 GCE Ramanagaram

Iw3m Window manager 2021-22

both floating and tiled windows. Floating window managers frequently support maximizing a
window, where it is resized to cover the screen, minimizing, where it is hidden, and resizing or
moving through moving the mouse after activating that functionality. This is also frequently called
“stacking,” but here we use the term floating to indicate the way the windows are placed. Stacking
refers to the ordering of windows by “stacking” them upon one another, but this describes
functionality used in switching windows, and does not explicitly refer to how they are placed. Tiling
window managers will frequently provide functionality to automatically resize a window, but will
also allow for manual resizing of a window’s allotted space, which will frequently result in the
resizing of other windows in accordance with the changes to optimize for available screen-space.
Windows are frequently hidden in tiling window managers through virtual desktops, but windows can
also be layered over one another. Virtual desktops, also called workspaces, assign a label to a group
of windows, where a user may then select a label and view the windows corresponding to that label.
Windows not associated with the corresponding label are consequently hidden. Both forms of
interaction will provide functionality to close a window, and often to open a new window by
spawning a new process.

Dept of CS&E 5 GCE Ramanagaram

Iw3m Window manager 2021-22

Chapter 4
Other Systems
4.1 Windows and macOS
Despite the plethora of X11-based window managers available, Linux and other Unix-like operating
systems only comprise an estimated 2.33% of the desktop operating system market, where X11 is
primarily used. Another 96.93% of the market goes to Windows and macOS, which have an
estimated market share of 89.01% and 7.92% respectively. Both operating systems have remained
largely faithful to the vision of the desktop laid out by Apple’s early attempts with the Apple Lisa and
Macintosh. Each uses floating window management as its primary style, with minor tiling features
included. Window decorations offer the primary source of interaction, with some keyboard shortcuts
allotted for specific actions. Native configurability compared to previously discussed window
managers is low, with few options being given to stylistic or functional customization. Owing to the
popularity of these windowing systems and the narrow scope of their feature set, we explicitly
enumerate their capabilities. Windows offers simple stacking capabilities, operated through the
window’s title bar decoration and the start bar, with corresponding keyboard shortcuts for most
actions. The window decoration presents three buttons: one to remove the window from the screen,
one to resize it to encompass the entire screen, and a third to close the window. Users are also given
basic tiling functions by dragging a window to the left or right sides of the screen. If desired, all
windows can be hidden through a button on the start bar. Basic virtual desktop functionality was
added in Windows 10, allowing a user to add a new desktop, add windows to that desktop, and either
switch to or remove that desktop. A menu is also offered to switch between windows, or, in Windows
10, a user can enter a view that displays all windows adjacent to one another, and raise and focus a
window from those. macOS offers slightly more advanced capabilities than Windows, but still shares
the majority of its feature set. When resizing a window to fill the screen, it may either be resized
within the current virtual desktop, to the limits of the menu bar and dock, or may be placed within its
own virtual desktop in a typical full-screen fashion. Windows un-maximized from their own
workspace will return to their original workspace. Two windows may be vertically tiled within these
full-screen virtual desktops, and the ratio of their sizes may be resized by dragging along the border
separating them. Wayland Wayland is a protocol that is intended to serve as a replacement to X. X
was originally developed in 1984 as network-transparent display system with the intention of being
run and displayed on different computers, one server and one client, respectively. This model is
considered outdated due to the current model of computing, where computers are sufficiently
powerful to render and display graphics in a single machine. Similarly, the complexity of the X
codebase has drawn criticism for its complexity and difficulty in maintenance. While Wayland has
been in development since 2008, it is still used by a minority of users of Unix-like desktop operating
systems. Sway is an early popular Wayland compositor and window manager written by Drew
DeVault et al. which seeks to closely replicate the functionality of i3. As of writing, it is compatible
with the majority of i3 features and commands, including i3’s configuration file format . The
Wayland protocol moves complexity that would normally be in the X server into compositors
however, resulting in Sway’s codebase measuring at roughly 21,000 lines of C code, despite being
roughly equivalent in features to i3, which is close to 16,000 lines.

Dept of CS&E 6 GCE Ramanagaram

Iw3m Window manager 2021-22

Way Cooler is a similar Wayland compositor and window manager written in Rust, which takes
inspiration from both i3 and Awesome. As such, it is scriptable in Lua and has planned compatibility
for Awesome. Way Cooler is written by Preston Carpenter et al. and consists of approximately 13,000
lines of Rust code . Currently Sway and Way Cooler are both built on the Wayland Compositor and
its respective Rust port. However, both have plans to respectively move to C and Rust versions of
wlroots, a new Wayland Compositor written by the authors of Sway and Way Cooler for providing
basic utilities for Wayland Compositors in a fashion similar to Xlib or XCB. Experimental Operating
Systems Experimental and research operating systems have the advantage over more established
systems of incorporating more advanced features deeper into their architectures, allowing greater
sophistication in higher-level applications. This is not always a product of the core operating systems
so much as the philosophies that guide the development of these operating systems, and 29the
changes enabling more experimental UIs often reside in the display servers, which generally can be
operating system-agnostic. However, these changes frequently are seen in the desktop environment of
the operating system for which they are built, due to the self-contained nature of most experimental
operating systems, which requires that they recreate their own versions of everyday tools. Haiku is an
operating system that aims to recreate BeOS, a now-defunct operating system created by Be, Inc.
Haiku offers a unique interface that noticeably differs from most other environments. It uses
TWM-style window decorations that only cover a portion of the top of a window’s upper border,
which aptly allows for windows to be stacked in a fashion similar to the tabbed features offered by
Ion. Windows can also be tiled by attaching their borders, which links them when one is moved or
resized. Similarly, windows can be moved across up to 32 workspaces, divided into a maximum of 16
columns and 2 rows. Each workspace is highly independent: moving a widget in one workspace will
not cause it to be moved in others, and eachcworkspace can have its own monitor settings. Haiku
uses the deskbar as the primary menu, whichcoffers menus for starting an application and lists all
currently-open windows much like the TWM icons menu. A study by Zeidler et al. showed that the
Stack & Tile features they wrote, which perform the aforementioned tabbing and tiling, improved
user effectiveness in managing windows, specifically with task completion times and interface
satisfaction . A2, formerly AOS or Bluebottle, is a new version of the Oberon operating system based
on the Active Oberon language. A2 uses the standard minimize, maximize, and close buttons within a
top-edge window decoration to control windows. Windows are all floating, and can also be resized by
dragging along the window’s borders. It supports an infinite large desktop, and allows windows to be
placed freely within this plane, even to be resized outside the boundaries of 30the screen. The
desktop can also be panned by moving the mouse to the edge of the screen and holding it there until
the desired coordinates are reached. A2’s UI is a Zooming/Zoomable User Interface (ZUI), which
was inspired by Jef Raskin’s suggestion that ZUIs are the next logical step in standard UI research.

4.2. Research Window Managers

Much like experimental operating systems, window management schemes arising from academic
research shed practicality in exchange for attaining loftier aims. Like many tiling window managers,
maximizing the utilization efficiency of a user’s screen and the amount of information they can fit on
their screen is a frequent goal found in window management research. Siemens’ RTL window
manager was built upon the belief that automatic tiling would best optimize a user’s screen space
according to the number of windows available. By making estimated guesses about which windows

Dept of CS&E 7 GCE Ramanagaram

Iw3m Window manager 2021-22

were important and could be reduced in size to accommodate windows estimated to be more
important, all windows could be fit on the screen while keeping most of the user’s desired
information on the screen. A two-dimensional space-tracking algorithm, called corner stitching was
used to make estimates based on how much screen space was empty and how much was used in
addition to the relative importance of the windows. Other systems like Elastic Windows [119] and
Bell and Feiner’s work in Dynamic Space Management for User Interfaces [120] have also focused
on algorithmically maximizing screen usage for user interfaces including window managers.
31WinCuts was also developed with screen utilization in mind, but took an alternate approach,
operating on the graphics of the windows as opposed to strictly the windows themselves. Rather than
resizing the windows themselves to fit all information on the screen, the relevant parts of windows
could be selected and mirrored in their windows, WinCuts, for the organization by the user. This
provided the user with greater flexibility, as by reducing the amount of information on the screen to
just what is needed, more information can be fit on the screen. Furthermore, WinCuts could be shared
with other users and could be used to construct new interfaces based on the parts of the component
interfaces in the WinCuts. Metisse also made use of directly manipulating the graphics of windows to
present new types of interfaces and interactions within the desktop metaphor. By allowing the user to
perform typical graphical operations on windows, such as scaling or rotation, it opened up the
possibilities for interactions such as zooming out a particular window or rotating a window for
viewing from a different perspective relative to the computer monitor.

Dept of CS&E 8 GCE Ramanagaram

Iw3m Window manager 2021-22

Chapter 5

Files
i3’s source code is in the src folder while header files reside in include. Other tools such as i3bar and
i3-navbar have their folders. i3 and its tools share an internal library called “libi3” which also has its
folder.The following list gives an overview of the codebase, explaining the functionality of the most
important, core source code files. Other files in the tree that are not mentioned here implement
specific functionalities: for example, src/scratchpad.c is obviously about the scratchpad functionality.

include/data.h

Contains data definitions used by nearly all files.

include/*.h

Contains forward definitions for all public functions, as well as Doxygen-compatible comments (so if
you want to get a bit more of the big picture, either browse all header files or use Doxygen if you
prefer that).

src/config_directives.c
src/commands.c

Contain the definitions for all high-level config and command directives. These are excellent places
to start with a top-to-bottom approach to understanding specific i3 behavior. For example, if you
want to investigate a bug that happens for the move to mark command, you can use gdb to pause in
cmd_move_con_to_mark and then work your way from there, stepping into lower-level functions.

src/con.c

Contains all functions which deal with containers directly (creating containers, searching containers,
getting specific properties from containers, …). Contains abstractions and auxiliary functions
necessary to work with the container structure which is used in almost all parts of the codebase.

src/tree.c

Contains functions that deal with the tree abstraction. However, be aware that src/con.c also contains
functions that heavily interact with the tree structure. Some functions that are included in str/tree.c
are those that handle opening and closing containers in the tree, finding the container that should be
focused next, and flattening the tree. See also src/move.c for other move-specific functions that
interact with the tree, which were moved into their file because they are so long.

src/workspace.c

Contains functions that deal with workspaces. Includes code that creates new workspaces, shows
existing ones, and deals with workspace assignments.

src/handlers.c

Contains all handlers for all kinds of X events (new window title, new hints, unmapping, keypresses,

Dept of CS&E 9 GCE Ramanagaram

Iw3m Window manager 2021-22

button presses, …). This is a very important file to understand how i3 interacts with changes to its
environment.

src/command_parser.c
src/config_parser.c

Contain a hand-written parser to parse commands and configuration (commands are what you bind
on keys and what you can send to i3 using the IPC interface, like move left or workspace 4).
src/config.c is responsible for calling the configuration parser.

src/click.c
src/resize.c

Contain functions that handle mouse button clicks (right mouse button clicks initiate resizing and
thus are relatively complex).

src/manage.c

Looks at existing or new windows and decide whether to manage them. If so, it reparents the window
and inserts it into our data structures.

src/match.c

A "match" is a data structure that acts as a mask or expression to match certain windows or not. For
example, when using commands, you can specify a command like this: [title="Firefox"] kill. The
title member of the match data structure will then be filled and i3 will check each window using
match_matches_window() to find the windows affected by this command.

src/randr.c

The RandR API is used to get (and re-query) the configured outputs (monitors, …). Legacy
Xinerama support resides in src/Xinerama.c.

src/render.c

Renders the tree data structure by assigning coordinates to every node. These values will later be
pushed to X11 in src/x.c.

src/sighandler.c
Handles SIGSEGV, SIGABRT, and SIGFPE by showing a dialog that i3 crashed. You can choose to
let it dump core and restart i3 in place (either trying to preserve layout or forget about it).
src/window.c

5.1 Thesis Window Manager

The culmination of this thesis is the creation of a new window manager that implements the concepts
found in state-of-the-art window managers and combines them on a platform that will allow for
extensive testing with a diverse set of workflows. The resulting window manager is forked from
StumpWM, and uses the Compton compositing manager to perform all zooming functions.

Dept of CS&E 10 GCE Ramanagaram

Iw3m Window manager 2021-22

Chapter 6
Data structures
See include/data.h for documented data structures. The most important ones are explained here.

The following picture is generated by the contrib/dump-as y.pl script.

Figure 6.1 contrib/dump-as y.pl script

The hierarchy is:

1. Root container
2. Output containers: EDP-1 in this example and the internal __i3+ output
3. Content and 2 dock area containers
4. Workspaces: Numbered workspace “1” and a “Named workspace”
5. Split containers: One horizontal in the first workspace and a tabbed one in the named one.
6. Leaf containers: Windows-like vim and an i3bar dock.

The data type is Con, in all cases.

6.1. Root container

The root container (global variable c root) is the up-most ascendant of every i3 container. It can be used to
iterate over the whole tree structure. E.g., it is used to reply to the GET_WORKSPACES request, iterating
over its children to find all workspaces. This is different from the X11 root window.

Dept of CS&E 11 GCE Ramanagaram

Iw3m Window manager 2021-22

The X11 root window (global variable root) is a single-window per X11 display (a display is identified by :0
or :1 etc.). The root window is what you draw your background image on. It spans all the available outputs,
e.g. VGA1 is a specific part of the root window and LVDS1 is a specific part of the root window.

6.2. Output container

Every active output obtained through RandR is represented by one output container. Outputs are considered
active when a mode is configured (meaning something is displayed on the output) and the output is not a
clone.

For example, if your notebook has a screen resolution of 1280x800 px and you connect a video projector with
a resolution of 1024x768 px, set it up in clone mode (render --output VGA1 --mode 1024x768 --same-as
LVDS1), i3 will reduce the resolution to the lowest common resolution and disable one of the cloned outputs
afterward.

However, if you configure it using xrandr --output VGA1 --mode 1024x768 --right-of LVDS1, i3 will set both
outputs active. For each output, a new workspace will be assigned. New workspaces are created on the output
you are currently on.

6.3. Content container

Each output has multiple children. Two of them are dock containers that hold the top and bottom dock clients.
The other one is the content container, which holds the actual content (workspaces) of this output.

6.4. Workspace
A workspace is identified by its name. You could think of workspaces as different desks in your office if you
like the desktop metaphor. They just contain different sets of windows and are completely separate from each
other. Other window managers also call these “Virtual desktops”.

6.5. Split container

A split container is a container that holds an arbitrary amount of split containers or X11 window containers. It
has an orientation (horizontal or vertical) and a layout.

Split containers (and X11 window containers, which are a subtype of split containers) can have different
border styles.

6.6. Leaf containers

A leaf container holds exactly one X11 window. They can’t have any children.

6.7. List/queue macros

i3 makes heavy use of the list macros defined in BSD operating systems. To ensure that the operating system
on which i3 is compiled has all the expected features, i3 comes with include/queue.h. On BSD systems, you
can use man queue(3). On Linux, you have to use google (or read the source). CIRCLEQ is necessary to go
from the currently selected window to the window above/below.

Dept of CS&E 12 GCE Ramanagaram

Iw3m Window manager 2021-22

Chapter 7

Startup (src/mainx.c, main())

● Establish the xcb connection
● Check for XKB extension on the separate X connection, load Xcursor
● Check for RandR screens (with a fall-back to Xinerama)
● Grab the keycodes for which bindings exist
● Manage all existing windows
● Enter the event loop

7.1. I3
i3 is a reparenting, non-compositing tree-based tiling window manager for X that was originally inspired by
wmii. i3 is targeted at advanced users and developers, and has stated design goals of
having well readable, well documented code, offering more flexible layouts using the tree as a data structure,
implementing different modes (like in vim; for example, in resize mode, other key bindings are active than are
in normal mode), implementing an inter-process communication interface, and not being bloated or fancy. i3 is
written in C, and interfaces with X using XCB. It supports tiling, stacking and tabbing modes, and allows the
user to switch between them dynamically. It implements both the ICCCM and EWMH

Figure 7.1 i3 with 7 self laid out tiled windows

i3 is configured by editing a plaintext file. This makes the window manager customizable without

Dept of CS&E 13 GCE Ramanagaram

Iw3m Window manager 2021-22

knowledge of programming. The contents of this file can be parsed and applied while the window
manager is running (that is, the user can instruct the window manager to reload its configuration on
demand). Windows are stored in a general tree (such as those brought up in Section 2.2.3), in which
dividers (called split containers) define either a horizontal or vertical arrangement of the windows
under it. In Figure 6.1 we have mimicked the layout presented in Section 2.2.3. Like other window
managers that are EWMH compliant, i3 can be used in conjunction with external status bars, docks,
and program launchers. The developers of i3 offer a status bar, called i3status, that is enabled by
default. Of course, if the user so wishes, this can be changed through the configuration file.

7.2. bspwm
bspwm (for binary space partitioning window manager ) is a non-reparenting, non-compositing tiling
window manager for X that represents windows as the leaves of a full binary tree. It only responds to
X events, and the messages it receives on a dedicated socket. In fact, it is so bare-bones that it does
not even handle keyboard or mouse input itself; an external program (such as sxhkd) is required to
configure and conveniently interact with the window manager. The external input handler is set up to
command bspwm using bspc, the window manager’s client program used to configure it, and to send
it instructions. Bspwm implements the ICCCM and EWMH, and offers multi-monitor support for
XRandR and Xinerama. Whereas i3 (figure 6.1) uses a general tree to represent its windows and is
therefore capable of evenly partitioning the window space amongst an arbitrary amount of windows,
bspwm’s splits only allow for two constituent partitions. In particular, this means that every internal
node has exactly two children.

Figure 7.2 bspwm with 7 self laid out terminal emulator windows

Dept of CS&E 14 GCE Ramanagaram

Iw3m Window manager 2021-22

Figure 6.2 shows a best attempt to mimick the layout we achieved with i3 in Figure 6.1. Because we
can only have local arrangements with two containers (being either a divider or a window), we do not
have exactly the same amount of flexibility we have in tree-based tiling window managers that
employ general trees. The terminal emulators’ prompts each denote their window’s width and height
ratio relative to the width and height of the screen, respectively. As can be seen, the window in the
top-left has a width of 30% of that of the screen, while the two partitions next to it to the right (which
appear to be its siblings, but are not), have an accumulative width of 70%, or 35% each. Ideally, like
in our i3 example, each would have the same width of 33%. Here is the tree that effectuates the
shown layout on screen.

Figure 7.3 Tree Structure

A new window can be added above, below, to the left, or to the right of a window. By default, both
windows will take up 50% of the designated window space. For example, if we were to add a
window below window 4 in Figure 6.2, window 4 will take up the top half of the screen, and the new
window will take up the bottom half. Split ratios can be adjusted; in our example, we can specify that
we want a split’s new partition to take up 70% of the window space. So, by adding a new window
below window 4, we get that window 4 then takes up 30% of the screen, and the new window 70%.
Besides manual splitting, bspwm also has automatic mode, in which windows are laid out along a
predefined layout, comparable to the approach in list-based tiling.

Dept of CS&E 15 GCE Ramanagaram

Iw3m Window manager 2021-22

Chapter 8

Keybindings
8.1. Grabbing the bindings
Grabbing the bindings is quite straightforward. You pass X your combination of modifiers and the keycode
you want to grab and whether you want to grab them actively or passively. Most bindings (everything except
for bindings using Mode_switch) are grabbed passively, that is, just the window manager gets the event and
cannot replay it.

We need to grab bindings that use Mode_switch actively because of a bug in X. When the window manager
receives the keypress/key release event for an actively grabbed keycode, it has to decide what to do with this
event: It can either replay it so that other applications get it or it can prevent other applications from receiving
it.

So, why do we need to grab keycodes actively? Because X does not set the state property of keypress/key
release events properly. The Mode_switch bit is not set and we need to get it using XkbGetState. This means
we cannot pass X our combination of modifiers containing Mode_switch when grabbing the key and therefore
need to grab the keycode itself without any modifiers. This means, that if you bind Mode_switch + keycode 38
("a"), i3 will grab keycode 38 ("a") and check on each press of "a" if the Mode_switch bit is set using XKB. If
yes, it will handle the event, if not, it will replay the event.

8.2. Handling a keypress

As mentioned in "Grabbing the bindings", upon a keypress event, i3 first gets the correct state.

Then, it looks through all bindings and gets the one that matches the received event.

The bound command is parsed by the i3 parser, see parse_command in src/commands_parser.c.

8.3 User commands (parser-specs/commands.spec)

In the configuration file and when using i3 interactively (with i3-msg, for example), you use commands to
make i3 do things, like focus a different window, set a window to fullscreen, and so on. An example command
is floating enable, which enables floating mode for the currently focused window. See the appropriate section
in the User’s Guide for a reference of all commands.

In earlier versions of i3, interpreting these commands was done using lex and yacc, but experience has shown
that lex and yacc are not well suited for our command language. Therefore, starting from version 4.2, we use a
custom parser for user commands and the configuration file. The input specification for this parser can be
found in the file parser-specs/*.spec. Should you happen to use Vim as an editor, use: source
parser-specs/highlighting.vim to get syntax highlighting for this file (highlighting files for other editors are
welcome).

Excerpt from commands.spec

Dept of CS&E 16 GCE Ramanagaram

Iw3m Window manager 2021-22

state INITIAL:

'[' -> call cmd_criteria_init(); CRITERIA

'move' -> MOVE

'exec' -> EXEC

'workspace' -> WORKSPACE

'exit' -> call cmd_exit()

'restart' -> call cmd_restart()

'reload' -> call cmd_reload()

The input specification is written in an extremely simple format. The specification is then converted into C
code by the Perl script generate-commands-parser.pl (the output file names begin with GENERATED and the
files are stored in the include directory). The parser implementation src/commands_parser.c includes the
generated C code at compile time.

8.1.1 Example: The WORKSPACE state

Let’s have a look at the WORKSPACE state, which is a good example of all features. This is its definition:

WORKSPACE state (commands.spec)

# workspace back_and_forth

# workspace <name>

# workspace number <number>

state WORKSPACE:

direction = 'next_on_output', 'prev_on_output', 'next', 'prev'

-> call cmd_workspace($direction)

'back_and_forth'

-> call cmd_workspace_back_and_forth()

'number'

-> WORKSPACE_NUMBER

workspace = string

-> call cmd_workspace_name($workspace)

Dept of CS&E 17 GCE Ramanagaram

Iw3m Window manager 2021-22

Chapter 9

Framework and Methodology

StumpWM was chosen as the base for the thesis window manager due to the flexibility afforded to it
by Common Lisp. This proved helpful for the power of the language itself as well as its environment,
where on-demand reloading made it possible to test new functionality without reloading the window
manager. StumpWM’s flexibility is also important to the goal of the thesis window manager to allow
for flexible management of windows. The thesis window manager presents a ZUI interface similar to
A2: the desktop can be freely zoomed, panned, and manipulated directly, without the need for any
special interfaces for interaction such as a pager. This functionality manifests itself in two modes,
which are largely invisible to the user. When no scaling is applied to the desktop, all windows can be
interacted with normally. Clicking on the desktop and dragging along it moves all currently mapped
windows, effectively panning the desktop. However, upon using the scroll-wheel on the desktop, the
“overview” mode is engaged wherein scaling is applied to all windows in the current workspace.
This causes the graphics for each currently-displayed image to shrink, and therefore allows for more
windows to be displayed on the physical screen. For simplicity, windows cannot be interacted with
using the mouse in overview mode. However, they can be moved and resized anywhere in the
currently visible area, and the desktop can be scaled as before. To re-enter the normal mode, a user
simply has to set the desktop to be unscaled. As previously mentioned, the two modes are largely
invisible to the user in that the transition between them only changes how the user interacts with the
windows and does not produce any visual effects that would distinctively separate them; the user
feels as if they are directly interacting with the desktop at all times. 33A compositor is needed to
manipulate window graphics in this way, which stores the image data for each window in a way that
is accessible by other functions within the display server or an external program for manipulation. In
i3, this is accomplished through the Composite extension, which allows the programmer to request
for a window’s pixmap, the i3 native image data format, to be made available in memory for
manipulation by the compositor. To accomplish this, Compton was used as an external compositor to
scale the window pixmaps and draw the resulting image to the screen. Compton was chosen since it
is an independent program and fairly small, measuring around 10,000 lines of C code. To
communicate when Compton should scale, its DBUS interface was extended to include functions that
specify the desktop scale, which is utilized by StumpWM when a user chooses a new scale. To
leverage the diverse functions offered by the thesis window manager with a mouse, an editable text
field, the command bar, is added to each window as a window decoration. It was repurposed from the
StumpWM input field and offers most of the same keyboard interactions and rendering capabilities,
but holds text in its buffer even after execution and is operable through the mouse. The command
bar’s interactions are similar to the tag pane in acme and universal text commands in Oberon, with a
left-click allowing the user to select text and place the cursor, and a middle click selecting the current
word, delimited by spaces. Text executed in the command bar is executed entirely at runtime and can
consist of pre-defined commands, StumpWM commands, Lisp functions, or terminal commands.
Commands are specified in a hash table and simply map arbitrary text to a specified command with a
preferred method of evaluation, i.e. the Lisp function that will evaluate the command. The command
bar is typically placed on the top of the window by reparenting the bar and the window to a single
parent window, making it functionally identical to bars in most floating window managers. However,
it functions as an independent window, and can also be placed on the top of the screen as a dock. All
command bars have their text buffer and can correspondingly be edited independently from other
bars. The initial text in a command bar can be set through a global variable configurable by the user.

Dept of CS&E 18 GCE Ramanagaram

Iw3m Window manager 2021-22

9.1 Architecture and Block Diagram

The i3wm Window System is based on a client-server model. The server controls display and input
devices, such as keyboard and mouse. The client is an application that receives input events from the
server and sends output and information requests to the server. The window manager is a special
i3wm Server client that has control over the layout of windows on the screen. To enforce this
authority, the window manager is using certain i3wm protocol features that will be discussed later on.

Figure 9.1 Architecture of i3wm

Figur9.2 Window setting and shift

Dept of CS&E 19 GCE Ramanagaram

Iw3m Window manager 2021-22

Figure 9.3 User interface

Dept of CS&E 20 GCE Ramanagaram

Iw3m Window manager 2021-22

Conclusions
This thesis has presented an academic survey of the architectures and designs of X11 Linux window
managers, both popular and lesser-known, in addition to other display systems on Linux and other
operating systems. It was found that there are very strong lines of heritage in X window managers,
owing to many of them being free software with easily accessible codebases. Furthermore, the
simplicity of some of these window managers has given way to numerous forks, some of which
improve upon the concepts implemented in their predecessors. All X window managers fall under the
categories of floating or tiled, though most tiled window managers support floating windows, and
furthermore, that tiling comes in dynamic and manual flavors, with numerous dynamic algorithms by
which to arrange windows. Some window managers also accept scripts from users, providing a layer
of abstraction that allows for a high level of customization. In the future, window manager
developers will likely move to develop for Wayland, which has been designed for use on personal
computers, as opposed to the terminal-mainframe style computing that guided the design of X. The
structure of Wayland will require complete rewrites of current window managers but provides new
opportunities through its ability to natively composite windows.
The window manager presented in this thesis has taken into account ideas from both academic and
non-academic sources to provide features not available in any single window
manager. Of note is its combination of an Oberon-style textual command bar with a pannable large
desktop and compositing to provide easy viewing and navigation of this desktop. To take advantage
of these features, algorithms were developed which operate on windows across a large virtual
desktop. Its compatibility with X, the default display system on Unix-like operating systems, and
intention for public availability under the GNU General Public License will encourage further
research. Features regarding the algorithms used to process windows and the structure of the window
manager has been proposed as potential places for further research.

Future Enhancement
The thesis window manager only provides a framework and a basic set of functions to showcase this
framework and provide a usable window manager. Further research would focus on features within
this window manager that make use of the ideas presented in this thesis. To separate different tasks,
users may wish to group their windows into clusters of windows about a particular task, in a fashion
similar to virtual desktops. To automatically determine which task a window belongs to, a clustering
algorithm could be written to cluster “connected” windows, defined as being within a certain absolute
distance of each other. In essence, a cluster is merely an index for a particular window graph and
does not hold any independent information on the windows it holds. To construct a cluster, a list of

Dept of CS&E 21 GCE Ramanagaram

Iw3m Window manager 2021-22

clusters and a hash table mapping each window back to its list index are initialized. The list of all
windows currently mapped to the display is then processed to determine the initial clusters by its
node, with edges in each direction to the closest window in that direction. If a window is connected
to the current window and has not been previously checked, it is added to the current window’s
cluster. Otherwise, it is placed in its cluster.

If the window has been checked but is connected, it is moved to the cluster of the current window.
This process repeats for each unchecked window until all windows have been checked, and the
resulting list of clusters is returned. To make navigating between windows more even as a product of
better alignment, a compaction algorithm could be developed that shortens the spaces between
windows. To accomplish this, it simply performs a breadth-first traversal of all nodes in the window
graph, starting at the root node, and shortens any edges greater than a certain length between
windows, updating the windows and their corresponding nodes on each compaction. The resulting
window cluster would have a uniform amount of space between each window. To fully make use of
the compositing used in the thesis window manager, “portal” windows, as outlined by Ben Bederson
in his work on Pad++, would be a very powerful feature to better integrate the ZUI with the desktop.
Portal windows would entail a window containing an image rendered by the compositor that marks a
certain scale and location on the desktop. Implementation could simply consist of rendering any
window pixmaps contained in the region of the portal inside its window. Interactivity would mostly
function as in the overview mode, and allow the user basic pager functionality. Anchoring the
position of windows relative to other items on the desktop would allow for more sophisticated
relationships between windows at a user-determined level. These could include “sticky” windows
that are not panned, and hold their size and location on the user’s monitor when the user pans the
desktop. This could also possibly apply to scaling to control how windows are scaled as the user
scales the desktop; however, this feature would need to be implemented with care due to the input
issues involved with scaling. Windows could also be attached to other windows, in a fashion similar
to Stack & Tile. The algorithms used to process windows in the thesis window manager provide a
good basic set of features, but also a path forward for future research. An interface by which the
current state of the desktop acted as input for a function for manipulating the windows on a desktop
would be useful in providing for new work. This would allow greater modularization in how
windows are processed and provide greater flexibility in how these algorithms are applied.
Interacting with an interface would provide a level of abstraction useful in prototyping these
algorithms, and would allow users to swap them out as necessary. For example, different clustering
algorithms could be used depending on the desired behavior. Research on additional algorithms to
use in processing windows would be one of the more obvious, but more conceptually-involved
additions to the framework outlined here.

The explosion of machine learning research could likely be applied to this problem, as windows
contain a significant amount of information about them aside from the coordinate-based algorithms
that have been demonstrated. Reinforcement learning could potentially prove a useful method of
learning which window a user would switch to next, by suggesting a window to switch to but
allowing for spontaneity in which window a user selects. Algorithms could also be devised which
take a greater role in the automatic organization of windows. An example algorithm would give the

Dept of CS&E 22 GCE Ramanagaram

Iw3m Window manager 2021-22

user different views of open windows on different virtual desktops. Views could entail clusters sorted
by program or program type, clusters arranged by how many different windows have been used, or
could organize windows such that more frequently used programs gravitate toward the center of each
cluster. The architecture of the system also could be a rewarding area for further research. The
primary components of the thesis window manager are largely orthogonal in functionality and could
be split into separate tools for window management, as in the case of WMutils. In this vein, the
command bar provides a good basis for text commands and customization but does not fully reach
the power attained by Oberon or Acme. In Oberon, any available text item can be used as a
command, as opposed to the limitation of the thesis window manager to only text in a command bar.
This could likely be accomplished with an i3 function call that captures any selected text. In Acme,
the core philosophy behind text commands is the ability to integrate with the existing system. Text
commands in Acme take their input and return their output to it, allowing external programs to be
called within Acme that are also usable as general-purpose tools. However, as the interface of the
thesis window manager is graphically based and not text-based, the majority of currently-available
command-line tools are not particularly useful. Despite this, the flexibility of the i3 protocol could
allow for the thesis window manager to pipe tools information about the current desktop and have
their output applied to the desktop. Output could also be pushed to an external window or even to the
tag bar itself, for example as in a function that reads from the system clock and outputs it to its
command bar. These functions would allow the thesis window manager to, like Acme, integrate with
the existing system and make the command bar a more powerful component.

References
[1] Vannevar Bush. As We, May Think.
https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-
think/303881/. 1945.

Dept of CS&E 23 GCE Ramanagaram

Iw3m Window manager 2021-22

[2] Douglas Englebart. Augmenting Human Intellect: A Conceptual Framework.

https://www.dougengelbart.org/pubs/augment-3906.html. 1962.
[3] Douglas Englebart. The Demo: 1968.
http://www.dougengelbart.org/firsts/dougs-1968-demo.html. 1968.
[4] Xerox Palo Alto Research Center. Alto User’s Handbook. 3333 Coyote Hill Road, Palo
Alto, CA, 94304, 1979.
[5] Inc. Apple. Mac OS X Leopard - Features - Spaces.
https://web.archive.org/web/20070710195557/http:
//www.apple.com/macosx/leopard/features/spaces.html. 2007.
45[6] Richie Fang. Virtual Desktops in Windows 10 - The Power of Windows...Multiplied.
https://blogs.windows.com/windowsexperience/2015/04/16/virtual-
desktops-in-windows-10-the-power-of-windowsmultiplied/. 2015.
[7] Michael S Bernstein, Jeff Shrager, and Terry Winograd. “Taskposé: exploring fluid
boundaries in an associative window visualization”. In: Proceedings of the 21st annual
ACM symposium on User interface software and technology. ACM. 2008, pp. 231–234.
[8] Desney S Tan, Brian Meyers, and Mary Czerwinski. “WinCuts: manipulating arbitrary
window regions for more effective use of screen space”. In: CHI’04 extended abstracts on
Human factors in computing systems. ACM. 2004, pp. 1525–1528.
[9] Joona Antero Laukkanen. “A scalable and tiling multi-monitor aware window manager”.
In: CHI’11 Extended Abstracts on Human Factors in Computing Systems. ACM. 2011,
pp. 911–916.
[10] Thomas M. Frey. “Bluebottle: A Thread-safe Multimedia and GUI Framework for
Active
Oberon”. en. Ph.D. thesis. ETH Zürich, 2005. DOI: 10.3929/ethz-a-004999723.
[11] ETH Zürich. Oberon Community Platform.
http://www.ocp.inf.ethz.ch/wiki/Documentation/Oberon. 2007.

Dept of CS&E 24 GCE Ramanagaram