skip to the content

back to the top

You may also find my log posts about this interesting.

What's this?

This is yet another window manager for the X windows system, in early development. I am writing this for two reasons, one of which is an experiment in development (which isn't really interesting). The other reason, the reason I am making this public, is to demonstrate a system for managing windows which I think is superior to what is already on offer.

I plan to create something similar (sharing code where possible) for win32 systems in the near future, too.

History

Classic Window Management

overlapping, occluding windows The classic window management paradigm (referred to as `floating') is thought by many to be critically flawed. Windows occlude each other, sometimes partially. Partially occluded windows must un-necessarily redraw parts of themselves that aren't visible, consuming resources in the process. This problem (at least) is being solved by a new X extension called XDamage.

The classic paradigm also does little to help the user with the actual management of windows. These problems are detailed on the ion window manager homepage.

Pane-Based Management

non-overlapping, paned windows One solution (implemented in the aformentioned ion) is to move to a pane-based paradigm. Screens are divided up into panes, summing up to 100% of the available space. Windows occupy an entire pane. Panes do not overlap, and thus most windows do not either. Some special windows (transients) overlap others.

This `well behaved' approach leaves windows where you put them. People who have adopted pane-based window managers recognise a massive improvement in productivity and satisfaction when interacting with window-based programs.

However, I think that this is such a radical departure from what people are used to that it will not be adopted by the majority of users. Although the X specifications and design do not dictate the classic-approach, many software developers have unintentionally broken their programs so that they only work properly in such a system, making adoption all the more difficult.

My Proposed Solution

My approach is not sufficiently implemented to be demonstrated, and I feel that words won't do it justice, so I won't bother trying to explain it very well (yet).

In short, my system will resemble the classic system so that you can pick it up as easily as you would use your existing system. However, windows will be managed as thoroughly as the pane-based system, albeit dynamically rather than statically.

Code

I am providing my makefile which works for me on a linux system and a cygwin environment in windows. Yes, this is not ideal. The code is distributed under the GPL (see COPYING). The included list.h is from the Linux kernel.

The code is in a very early state: you can use it to manipulate very simple windows but sub-windows, MWM_HINTS (borderless) windows etc. will not work yet. 

COPYING (18K)
Makefile (1014)
list.h (7.3K)
wm.c (13K)

Helpful things