glue

In this article we will put some light on a lot of tools used in the world of Unix desktop environment customization, particularly regarding wmctrl, wmutils, xev, xtruss, xwininfo, xprop, xdotools, xdo, sxhkd, xbindkeys, speckeysd, xchainkeys, alttab, triggerhappy, gTile, gidmgr, keynav, and more. If those don’t make sense then this article will help. Let’s hope this can open your mind to new possibilities.

NB: A lot of the questions regarding those tools and what they are usually come from people that don’t actually grasp what the purpose of a window manager is or what desktop environments are. If this is the case please read the following before starting:

However, even without reading the previous content, this article will try to explain concepts as simply as possible.

With that in mind we can wonder if what’s actually needed from a window manager, presentation and operation, can be split up and complemented with other tools. We can also start thinking laterally, the communication and interaction between the different components of the environment. We have the freedom to do so because the X protocol is transparent and components usually implement many standards for interfacing between windows. It’s like gluing parts together to create a desktop environment.

The tools we’ll talk about fall into one of those categories:

Debugging
Window manipulation
Simulation of interaction
Extended manipulation
Hotkey daemon
Layout manager

overview

Window Manipulation

Windows are objects living in the X server that have a visual representation when mapped on the screen (viewable and visible). Windows, like any other objects, have attributes and properties attached to them. Another interesting object within the X Server is the pointer aka cursor.

The tools in this section manipulate those bare objects using the X11 protocol to speak to the X server. They do things such as list the identifiers of the window objects within the X server and their basic properties, they let you do basic tasks on them such as moving them, resizing them, changing their stack order (which one is above the other), labeling them, hiding/unmapping them (or the opposite by mapping them), changing the focus from one to the other, and as an extra some also allow to manipulate the pointer position and cursor shape.

Two popular tools that offer those functionalities are wmutils core and the window utility from jessies x11-extras softwares. Along with those come some other utilities used for window listing such as winselect also from jessies, xlsw from baskerville, and the one included within wmutils core lsw. We could also mention single usage tools such as xkill.

The philosophy behind wmutils is more Unix-like, portrayed as the “Coreutils for Xorg” it’s less monolithic than a lot of similar tools we’ll see which renders it useful on the pipeline. Moreover, it’s written using the XCB which is more of a direct correspondence with the X protocol.

We can manipulate the windows basic object but how do we actually verify that the change has been done properly. This can be done using debugging utilities such as xwininfo or xwinfo.

We should also mention a particular one that is p9-like, the x11fs that does the manipulation though a virtual filesystem API.

Simulation of interaction

So far so good, we’re able to do some basic actions on windows but what about simulating inputs such as keyboard or mouse, in the same way as winmacro on Windows platform or headless browser for the javascript world.

This is possible if the X Server implementation comes with the XTEST extension which as you would’ve guessed was principally added to test the server without having user interaction.

Most popular implementations builds (X.org Server) nowadays come with this extension however you can make sure that it’s there by querying the list:

xdpyinfo -display :0 -queryExtensions | awk '/opcode/'

Which should return a line similar to this:

...
    XFree86-VidModeExtension  (opcode: 153, base error: 172)
    XINERAMA  (opcode: 141)
    XInputExtension  (opcode: 131, base event: 66, base error: 129)
    XKEYBOARD  (opcode: 135, base event: 85, base error: 137)
    XTEST  (opcode: 132)
    XVideo  (opcode: 151, base event: 93, base error: 155)

Thus, a set of utilities such as xdotool and xdo use this extension to simulate inputs. Most of them also include the behavior of the previous tools, especially the listing of window identifiers, this is a bit redundant.

Another interesting one is keynav, the “retire the mouse” tool that let you control all mouse functions from the keyboard efficiently, splitting the screen into sections.

Extended manipulation

A standard called icccm (Inter-Client Communication Conventions Manual) was devised a long time ago between 1988 and 1989, and another one named EWMH (Extended Window Manager Hints) not long after builds upon it. Both are used for lateral communication between windows. Their main purpose, which you can guess by taking a glance at them here and here , is that they emphasize on giving information about components and creating the interface between the standard components that usually make up a desktop environment such as bars, panels, desktop and all that is related (managed windows for instance), viewports, state of the window, title of window, the current focus, and much more.
A window manager or a client can choose to implement all or parts of those standard (respond to events), for example you can find the list that Openbox supports here.

Naturally, there’s yet again a set of tools letting you manipulate those properties however keep in mind that they only have an effect if the EWM/NetWM atoms (it’s the name of the properties) are respected. wmctrl accesses almost all the EWMH features, xtitle as the name implies accesses only the title, xdotool previously seen can also access some features (moving between desktops).

Lastly, the debug command line utility that is useful to display such window properties is xprop.

Hotkey daemon

What if instead of having the window manager catching the keys you press you had another application listening to your keys and performing actions whenever it encounters certain combinations. This is the job of the hotkey daemon. The explanation couldn’t be simpler, assign keys to actions.
Examples of such are xbindkeys, speckeysd again from jessies x11-extras, sxhkd a popular one and yet another tool from baskerville, triggerhappy, xchainkeys which works by creating a chain of keys, devilspie2 which takes action on certain EWMH events, and alttab which is for task switching (keybind mixed with the window manipulation).

But how do you make sure, if there’s an issue, that your hotkey manager responds to the right keys or which keys to set in its configuration. The xev let you debug X input events in general.

Moreover, it’s good to note that you can debug anything seen previously in more depth using xscope, xtruss, or x11vis. However, most of them are a hassle to set up, xtruss is the easiest to compile and use in my opinion.

Layout manager

In normal cases it’s the job of the window manager to choose where to place windows on the screen and their layout but there are separate programs that can be used for this. Generally the layout manager program add tiling feature to a window manager that doesn’t have tiling.
This can be achieved using a software that specializes in this such as gTile for GNOME or gridmgr for others. Or it could be achieved by combining a hotkey daemon along with a window manipulation tool, so let’s say sxhkd with wmutils for instance.

This puts into question the role of the window manager if you can have all of its behavior into separate entities.

Summary

Debugging the protocol in general
- Action: xtruss, xscope, x11vis
Window manipulation
- Action: wmutils, window, x11fs, xkill, ..
- Listing: xlsw, lsw, ..
- Debug: xwininfo, xwinfo
Simulation of interaction
- Server Extensions: xdpyinfo
- Action: xdotool, xdo, keynav
Extended manipulation
- Action: wmctrl, xtitle, xdotool
- Debug: xprop
Hotkey daemon
- Action: xbindkeys, speckeysd, sxhkd, triggerhappy, xchainkeys, alttab, devilspie2
- Debug: xev
Layout manager
- Action: gTile, gridmgr, any combination of the above ..

Examples

What can be done with all this, let’s push some ideas.

Starting your graphical session with a specific layout everytime regardless of the window manager
Automate a user action inside your program, in test units for example
Beautify your desktop with conky and make it clickable like a panel
Automate captcha
Dump your window manager entirely and have pieces in separate programs instead

… And much more.

There’s really nothing you can’t do that a window manager can do.

Conclusion

We went over a lot of tools in this post, we covered basic manipulation, to extensions, to simulation of inputs, to listening for your own inputs to take action. The glue thinking should make sense now, the freedom to build and customize your environment the way you want.

Let’s close this post with something that might be confusing for some. In the reddit community called /r/unixporn users tag their posts with the window manager they are using. Some entries are tagged as wmutils but after reading this article you’ll realize that in fact wmutils is not a window manager in itself. Those post should really be tagged “No WM” however that would be confusing as the line is thin between the definition of a window manager and the glue that could possibly be created using the tools in this post.
Another window manager that is missing the operation part is bspwm and it’s usually accompanied by sxhkd, but that sxhkd (hotkey daemon) can be used with any other lightweight window manager such as monsterwm, dwm, catwm, or no window manager at all.

There’s no limit to what you can do, enjoy playing with glue.

Adding Glue To a Desktop Environment