OneAndOneIs2

Why can't you fix FVWM, or one of those other WM's you mentioned? Surely that's easier than writing your own.

Sounds like somebody doesn't have enough to do at work :p

@Vincent - Because it's easier to hack a small codebase of your own than it is to get to grips with an existing, massive project.

Academic at the moment anyway - I've installed the latest version of FVWM2 and hopefully it won't suffer the bugs the older version I was using had.

I actually have some thoughts on that. I built a window manager (Lucca WM, google it if you care) in college using GTK, and came to the conclusion that I (and nearly everyone else who has ever built a window manager) had done it wrong.

I structured my window manager in two layers, the "core" layer and the "xwm" layer. The idea was that xwm would take care of all the details of the X protocol, ICCCM, EWMH, and the various hacks that any WM unfortunately needs to work well with some broken programs and libraries, while the "core" layer would handle the policy: when to reparent, when to focus, when to move things to where. The "core" part of the program didn't even link Xlib; it simply used gtk and xwm. That was a good idea, but I did it wrong.

First of all, I made xwm a source library instead of a shared library. That meant that it could only ever be used from a C program. If I had made it a shared library (and if gobject introspection had existed at the time), it could've been usable from any programming language supporting gobject introspection, not just C. (As it is now, most window managers are not only implemented in pure C, they're implemented in pure X11, with no toolkit. While it's certainly possible to use a toolkit, and I did it, it's not easy.)

But that's a minor problem, easily addressed. The real problem is with what happens when you use xwm in the most trivial way possible, firing it up and then doing nothing but let it run.

What actually happens is that you get a broken desktop. It's worse than no window manager, because the WM will intercept the requests from applications to map their windows, and completely ignore them. There's some minimal amount of code you need to make a usable WM, and a user writing a new WM would typically start by copying an existing one. That's bad.

What should happen is that you get a fully ICCCM- and EWMH-compliant window manager with the simplest possible policies. So when xwm gets a map request, it should (if the program using it does not handle the request) simply map the window. When it sees a dock, it should (if not told otherwise) dock that window and subtract the appropriate area from the work area, which it reports to all other X11 programs in accordance with the EWMH standard. When it gets a request from a pager to focus a window, it should (unless told otherwise) simply focus the window. When someone clicks a window, the click should go directly to the window because no policy was set that says it should be intercepting clicks.

I like to call this hypothetical window manager "nullwm". In nullwm, all your programs work, but it doesn't give you a way to focus, move, resize, minimize, maximize, or close them. If you have another EWMH-compliant program running that gives you a way to do those things, it'll work. This would be a real test program, that I would actually build, were I actually writing a WM library.

I like to think that starting from nullwm (which is a nearly empty codebase) would be easier than starting from scratch, which you seem to think is the easiest method. If you don't care about how docks work, you can completely ignore them and let the library handle it for you, notifying you when the resulting work area changes. You could focus on the policies you actually care about. It'll need some good documentation of course, but I don't think getting there would be very difficult.

Unfortunately, this would require a redesign and rewrite of xwm, and I never bothered to do it. To be worthwhile, I would need at least one potential user other than me. So I guess what I'm getting at is if you do ever decide to write your own WM (and I still think you probably shouldn't), let me know and maybe we can collaborate.

It was your blog that actually inspired me to look into lightweight window managers. I had been using Fluxbox for a while but have since moved to awesome (a tiling window manager). I thought that the move would be difficult but I managed to pick it up in a couple of hours. As for the problem you mention moving the mouse between monitors, the default key mappings for awesome take care of pretty much any way in which you would wish to manipulate windows. It's also nice to be able to use 100% screen space all the time. Also, using chromium/firefox vim extension plugins and the apvlv pdf viewer, I have found that I no longer really need to use my mouse at all! Also, a point that's worth mentioning is that it can utilise gnome applets as well, such as volume control or network-manager plugin if that's your kind of thing.

Anyway, point is... you should check it out if you get the time.

Richard

I've recently switched to XMonad and after a bit of learning curve, I've been very happy with its minimalism and ability to customize behavior. Admittedly, I've had to learn some Haskell.

and Haskell is on my list of languages to learn when I have time. I'm reading through http://learnyouahaskell.com in my rare spare time..