Modern ways to write a window manager

Question

I'm trying to write a window manager. (Actually, I have written an OS and a compiler, but that's beside the point.)

XLib and xcb aren't exactly nasty, at least not by, say, win32 standards, but they are definitely very old and don't lend themselves nicely to decent abstractions to make my life easier. Not only that, but there's a distinct lack of good bindings for modern high-level languages.

My question is: is all this low-level stuff really necessary these days? Do libraries exist that will encapsulate all the nasty stuff for me? I have a vague memory that the Enlightenment people had done such a thing, but can't find anything. Or do modern widget libraries like, say, GDK have enough functionality that I wouldn't need to touch the Xlib layer?

Any libraries with Java bindings are of particular interest...

Acclaim

Nice question. Don't you just need pixel-by-pixel rendering capabilities? There might be some tricks to it, but that's how I'd start. – Megohm

I'd look at kwin, metacity, compiz and/or enlightenment. For my part, I like low level, and have only looked at WM's done using raw Xlib. With a bit of luck, Havoc Pennington will notice this question :) – Scottiescottish

Haskell has decent X11 bindings that were used to write the window manager Xmonad. – Tuggle

See also https://mcmap.net/q/333075/-building-a-window-manager-closed – Vesicant

Answer 1

This is a late answer so maybe it doesn't have much relevance anymore but I'll post it anyway since other people might be looking for it...

I have asked myself the same question and came to the conclusion that there exists no such thing, especially not in Java. While certain widget toolkits, like qt, offer you the possibility to use an existing display struct and create widgets out of existing xlib window handles, you'll still have to use xlib/xcb to do the nasty job of communicating with the X server for wm specific operations. Other libraries, as stated by others, like GDK and the enlightenment also offer a pretty good job of basic abstraction.

Still, I wasn't happy with the fact that all of these use C/C++ and sitting on my lazy ass waiting until somebody did the work for me in Java wasn't an option, I started writing my own library that allows you to build your own modular WM, in Java. https://github.com/Zubnix/trinityshell

Ambulator

I'm very interested to see this. Right now I'm immersed in other stuff, but I'll certainly have a look in the future. Let us know how you get on! – Acclaim

Answer 2

is all this low-level stuff really necessary these days?

If by "low-level stuff" you mean the C language then no, it isn't necessary from a technical standpoint; you could use XCB's XML to generate bindings for any language.

However, if by "low-level stuff" you mean dealing at the X protocol level then, yes, it is necessary (if you don't want to pull your hair out). A Window Manager must work at the X11 protocol level, so using something "high level" will only make your life difficult. In fact, XCB was created precisely because Xlib was too high-level, masking too much underneath so it was easy to make mistakes, and making it difficult or impossible to have full control. (Also, XCB is not "very old" from an X perspective; it is only in the last few years that all the major Linux distributions finally started fully using XCB.)

Adenoidal

good answer. the best high level approach is probably to start with an existing WM. also, an option could be to follow gnome-shell in using JavaScript. XCB and gobject-introspection both give you tools to automate language bindings if you have another language in mind. – Jenninejennings

btw, since the future direction is that a WM has to work as a CM also, and overall that's a little rocket-sciencey, I think there'd be a big argument for using the C part of gnome-shell and swapping out the JavaScript part (more or less), if your goal is an alternative UI. The UI decisions should largely be in JS, but the paint loop and low-level gunge in the old metacity bits and in the clutter C bits. – Jenninejennings

I respectfully disagree: there doesn't seem to be much to window managers that's particularly exotic other than the special window manager events and XGrabKey(). In fact, since I posted my question I've been hacking with gdk, and it very nearly does a lot that I want; I've got code that manages windows (in a very primitive way) almost entirely from the GdkWindow domain. Alas, the things it doesn't do are pretty nasty. In particular, gdk does very weird things with keyboard input and if XInput is available will ignore KeyPress and KeyRelease. Guess which events XGrabKey() sends? Right. – Acclaim

...and I will also add that gdk is in part a thin wrapper around xlib, which helps a lot. So I'm mostly implementing the same logic that I would use in xlib in gdk. gdk makes it much less irritating, though. I'm still looking for a decent WM abstraction layer; maybe my proof-of-concept code will become one. – Acclaim