Questions and Answers # Why a tiling window manager? # There are two basic arguments in support of tiling window managers: * They make sense * They are more keyboard friendly The fundamental idea behind a tiling window manager (or at least behind most tiling window managers) is that if the user wants a window displayed, it should be displayed. This means it should not be obscured by other windows, and that it should be given as much screen space as possible. This seems to make sense; After all, why would a person want to see a window, but only partly blocked by another? The guiding principle then is that if a user attempts to display a window, the window manager should display the window, and it should display it giving it as much of the screen as is available. If the space available is larger than the window needs, the the program can decide how to use (or ignore) the extra space (or the user can reallocate space himself, giving it to a window that is more important or just needs more space). If the window gets less space than it wants, again, it can decide what to display and what to drop, or the user can choose to free up space to give it (by resizing it, or by minimizing or moving unneeded windows). Further it seems obvious that the current floating window model is fundamentally broken: the model where the window manager simply vomits the windows onto the screen and leaves the user to sort through the mess. This model gained popularity, it appears, because in the 80's it seems hip (much as some current eye candy WMs are popular, not because they are more usable, but because they seem futuristic and cool). A computer desktops is not like a real desktop, windows are not pieces of paper that we pick up and move around. This is a general problem with the WIMP interface: Modeling a computer interface on physical objects (so you can point to them, drag them around, etc.) might be good for initial learning, but it is generally far from optimal efficiency. I wish that my desk would hide papers that I'm not using, and organize the ones I am to be non-overlapping, without my having to pick them up, sort through them, and meticulously arrange them. Of course this model quickly became the de facto standard, and thus it is what most people today are comfortable with. But to a person accustomed to a decent tiling window manager, going back to a floating window manager is painful, all the awkward window moving and resizing is an exercise in frustration and an utter waste of time. To see how this model is fundamentally broken consider how it has become popular, sometimes expected, for individual programs to implement their own screen multiplexing mechanisms (most popularly tabs, but also the horribly unusable sub-window paradigm). The fact that today every major web browser (and many other programs beside) come with a tabbing system is evidence of the fact that the old model of window management is incapable of handling large numbers of windows in a usable way. (Some other favorite bad ideas of mine or compositing--the point of a window is to see them, why would I want my windows to blur together?--and the desktop--let's put all the most important things in a place that will be the first to be inaccessible when the interface is used!). The second benefit of tiling window managers is that they lend themselves nicely to keyboard control. Again, most people are used to manipulating windows with some sort of pointer and don't notice the awkwardness (for example of trying to get the pointer right over the border to resize a window), but for a competent user, keyboard shortcuts are (able to be) much faster. (If you doubt that the keyboard is a faster way of interacting with a computer, then euclid-wm probably isn't for you.) # Why _another_ tiling window manager? # The window managers I was aware of all seemed to lack something. The specific things I wanted were easy, intuitive dynamic layout, and a graceful way to handle minimized windows. scrotwm was a huge inspiration. It's interface was dead simple to learn, and very intuitive (it got me hooked on tiling window managers). But it was a bit limited in its layout, and it's stack didn't unmap windows; Windows in the stack were mapped, they were just small: thus windows in the stack (a) always took up space and (b) became difficult to identify as the number of windows in the stack grew. wmii also had a lot of things that felt right: I really liked the minimize (stacked layout) idea, but I didn't like the fact that the stack was per cell as opposed to per desktop. With i3 I liked the ability to move windows with hjkl, and to use these keys to make new columns and rows. But I didn't like the table paradigm, which would leave empty cells, unless the user explicitly told the window to span the cells. So I decided to take what I liked and build euclid-wm. # Why Xlib and not XCB? # The big advantages of XCB are that it reduces latency (by allowing asynchronous communication with the X server) and that it allows a more low-level access to the X protocol. The disadvantages of XCB (compared to Xlib) are that it is new (far less documentation) and that (because it is less abstracted from the protocol) it requires more work. The fact that it is new means not only is there much less documentation, but that there are fewer projects to look at when you need an example. As to the advantages of XCB. I didn't need low-level access to the X protocol. I also wasn't concerned with the latency. Xlib has been fast enough--even over network connections on 80's era hardware--for a long time. Shaving 90% off a negligibly fast operation doesn't give much real benefit. (This isn't to say that there aren't modern applications that might benefit from such a speed-up, but a minimalist WM like euclid doesn't seem to be one of them.) I'm not sorry for this decision: euclid, has no issues at all with not being responsive, and trying to implement it in XCB might well have kept me from finishing it. # Why no multihead support? # I don't have a multihead setup. Thus I lack both the motivation and means to implement such support. If you want multiscreen support you have three options: 1. Donate a multihead setup to me. 1. Write a (good) patch yourself and submit it. 1. Offer to work with me to develop a good patch (I have a pretty good idea of what would need to be done to get it working).