X and the misleading claim of 'mechanisms not policy'

May 9, 2011

One of the mantras of X has always been that it provides mechanisms, not policy; the policy is up to whatever you run on top of it. So X does not dictate a specific look and feel, or even how windows are managed, and boosters of X are quite proud of this. Various X programs have adopted some close variant of this mantra for their own guiding principle; for example, I believe that a fair number of window managers take this approach (especially fvwm-style window managers). The problem is that this has always been an exaggeration. X is not as policy free as it likes to pretend, because the choices of what mechanisms it offers constrain your choice of policies. As an example, let's consider window placement.

In theory, X is policy-free on window placement; your window manager can position new windows however it wants. It can tile them, it can automatically place them in some optimal way (as many modern user-friendly window managers do), it can let people choose their locations in any number of ways, and so on. All of this works. Now, let us consider another way to handle placing new windows: you pick a menu item, for example 'new terminal', immediately sweep out where you want the new terminal window to go, and then it appears there.

(Let us call this the Blit method of window placement.)

You cannot implement this window placement policy in X, at least not in a way that lets you work with existing X clients. This is because the mechanisms that X supports for window placement are all asynchronous methods; they contain the fundamental assumption that creation of new windows is outside the control of the window manager. New windows just show up and the window manager has to deal with it. There is no mechanism to create a window and hand it to a program to use, nor is there a way to link an earlier window manager action to a new window from a new program (so your window manager cannot have you sweep out the location of the new window, remember that it is for terminal window such and such, start the terminal program, and when the program creates that window the window manager already knows where it should go).

Similar limitations on the possible policies can often be found in X programs that have adopted this mantra. For example, I suspect that many 'mechanisms not policy' window managers could not be used to create a tiled-windows environment; the mechanisms that you'd need for such a thing fall outside the mechanisms in the construction kit provided by the window manager.

(Sometimes you can fake it and it will mostly work, just as you can sort of fake the Blit method of window placement under limited circumstances.)


Comments on this page:

From 12.94.77.210 at 2011-05-10 16:52:59:

Would you care to share the window manager you have constructed from the fvwm toolkit?

By cks at 2011-05-10 17:16:40:

You can get an idea of how it looks from my desktop tour.

Written on 09 May 2011.
« Fvwm as a window manager construction kit
The different ways that you can lose a ZFS pool »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Mon May 9 00:25:35 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.