TinyWM – A tiny window manager in around 50 lines of C

[zeveb]

I think that the real advantage of something like this is that it provides a minimal template to follow if one wants to start writing a window manager in one's language of choice (assuming that language already has some X bindings). One can start from there, & then add ICCCM, tiles, whatever else one wants.

edit 1: accidentally a word

edit 2: I'm at a loss at why this isn't considered a contribution to the conversation. Can anyone enlighten me?

[equalunique]

I don't have a problem with your comment. FYI just wanted to let you know that the point you made is proven by the go port discussed here: https://news.ycombinator.com/item?id=17766249

[collinglass]

I ported this to go for fun 3 years ago: https://github.com/collinglass/tinywm

[rhymenoceros]

Nice! Ironically the Go version is much longer, mostly due to the interop overhead (and partially due to the code style).

[Y_Y]

Spent some time trying to get this to run in a Xephyr window on an old ubuntu box, but it doesn't seem to be able to move windows or resize as advertised (whereas twm is fine, and xev sees all the keypresses).

These tiny projects are often cursed by having very few resources when something goes wrong.

[lunchables]

Finally, a window manager for people who find dwm bloated!

[keithpeter]

Odd that you should say that...

I'm after a 'window manager' that can help me load a single X application on top of an X session that can sense the size of the screen and render the window maximised.

If you try something like

     startx /opt/openoffice4/program/soffice

from a linux console without a desktop manager set, you get an openoffice (whatever app) window that is a bit smaller than the screen and offset. Googling around suggests that you have to rely on each application to set its window size.

     startx /usr/bin/chromium --kiosk

will get you something close to what I'm after for all applications.

[dmos62]

For anyone pondering minimal/unbloated window managers, checkout cwm [0][1]. I've been using it exclusively for quite some time now. It's quick to compile, has sane configuration and is the most ergonomic floating wm I've used. I don't see myself ever needing anything else, provided I don't see myself using a tiled wm.

[0] https://github.com/chneukirchen/cwm [1] https://man.openbsd.org/cwm.1

[rambojazz]

Thanks for sharing. I'm a GNOME user but I want to try something lighter so I'm learning everything about "windows managers". I have never heard of "cwm" before, the only "cwm" that I was aware of is the "closed world machine" [1] so I was very confused at first :) Going to try it now, I wonder how it compares with awesomewm.

[1] https://dokk.org/manpages/cwm.1

[cultus]

I use it too. It gets out of my way better than other window managers/desktops I've used. It's amazing how much good stuff comes out of OpenBSD despite the limited manpower.

[jstimpfle]

I wrote something like this once, and had maybe 3-4 applications that I wanted to use with it. mplayer was one of them, and it broke with my straightforward and absolutely reasonable window manager. It did display only a quarter of the movies since it thought the video window was fullscreen but it was only a quarter of the screen. The reason was a bug in mplayer's source code. It did not expect to be resized once and only once and being mapped only afterwards.

Another story, I've been an icewm user for many years and I absolutely loved it. But at some point the bitrot was too much. Windows that didn't gain focus because of newer unimplemented client<->WM protocols, clients that crashed for hard to debug reasons, and so on. There are still some patches being developed for icewm that try to make it work with some newer clients. And there are workarounds on top of workarounds for fighting with Java clients, but at some point I decided it was too buggy and switched.

Writing a window manager could be such a nice project if wouldn't mean implementing terrible but necessary protocols, and fighting with all the bad X11 clients out there.

[danmg]

This reminds me of the mid-to-late 90s where everyone made their own window manager. You had the choice of 100s of them. But usually they lost interest after a version or two, and didn't implement much of the icccm.

[swiley]

There still are quite a few that are actively maintained and implement icccm.

That's something that bothers me about wayland. There really is a lot of variance when it comes to people's preferences about window decorations and focus behavior and so on. Having the applications handle it themselves is going to result in a lot of lost functionality/configurabilty.

[the_duke]

icccm?

[teddyh]

As far as I can tell, not ICCCM (nor EWMH/NetWM) compliant.

[rikkus]

This is important. But it's still great for people to see that a minimal implementation (for playing with) only takes this much code. It's good when you're learning.

[amarant]

this is so cool, I've been wanting to learn more about windowmanagers for a while now!

Any chance anyone knows of something similar to this but using Wayland as opposed to X?

[Sir_Cmpwn]

Not a snowball's chance in hell of doing a Wayland compositor in 50 lines. OP has the benefit of the X server doing most of the work. Wayland compositors also have to do all of the rendering, input dispatching, GPU setup, etc themselves. With wlroots you could probably get pretty small, though, but you still have to do rendering et al yourself: https://github.com/swaywm/wlroots (note: I am the maintainer of this software)

[kbumsik]

While X is a giant program that offers a lot of features, Wayland is not a program but a protocol. Wayland composotors, implementations of Wayland protocol, are usually intertwined with their desktop environments. So I guess similar examples using Wayland are not as universal as using X and do not help much to learn about Wayland itself.

Still, there is a convenient Wayland compositor library that is designed for devs to build own window managers. Check wlc [1]. wlc has a nice and simple example [2] but not as short as TinyWM.

[1]: https://github.com/Cloudef/wlc

[2]: https://github.com/Cloudef/wlc/blob/master/example/example.c

[mrweasel]

All the simple "window managers" for Wayland seems to be tiling for some weird reason. I think Wayland adoption could be higher is if there was a simple, easy to customize basic WM that people could fork to go do their own thing. I know Weston exists, and others, but if you look at how many X11 Window Managers that have been forked of AWM or EvilWM then perhaps Weston is a little to complex.

[znedw]

I use a mix of wmutils[0] and windowchef[1] and they're great, lots of little programs (some < 10 LoC) but also some cool stuff like mouse support and borders etc. I've only ever had trouble with JAVA apps which is a simple fix (_JAVA_AWT_WM_NONREPARENTING=1)

This is a screenshot of my Linux desktop [2], I use these on OpenBSD as well without too much issue.

[0] https://github.com/wmutils [1] https://github.com/tudurom/windowchef [2] https://i.redd.it/ql1id3rocnq01.png

[drudru11]

Very clean screenshot.

How does your setup fare with GL/Vulkan, Chrome?

[microcolonel]

https://github.com/xorgy/ldwm/blob/master/ldwm.c#L1799

Found that one out after some digging, seems weird to me that AWT manages to screw this up, to this day, maybe I'll understand what cool trick they do which makes this a problem.

> I use these on OpenBSD as well without too much issue.

Portability is a major benefit of these little window managers, I even ran my dwm fork on Minix3 (on real hardware!), with some minor Make changes [0] as a bored teenager.

[0]: https://github.com/xorgy/ldwm/blob/master/config.minix3.mk

[teddyh]

Too bad it uses the old Xlib instead of XCB.

[miguelsm]

Here's an XCB version: https://github.com/rtyler/tinywm-ada/blob/master/tinywm-xcb....

[__s]

This was a reference for me while initially developing nobox: https://github.com/serprex/nobox/blob/master/nobox.c

[oh5nxo]

Strange to use 0x0 instead of NULL in XOpenDisplay().

[erikb]

Is the xlib here as framework really the right backend? I have not much skill in this area so I can't say. In web development when someone claims he's written the shortest version of A and imports library B then usually the actually important code is written in B and he simply used A to configure the library to give the corresponding outputs he desires. Like "I wrote the shortest calculator ever: import Windows.Calculator; new Windows.Calculator();"

[wk_end]

xlib is effectively as low-level a library as a WM might possibly use. This is like writing a calculator using the raw Win32 API, not some calculator library.

[amelius]

If it were more involved to write a WM, then I'd say that would be an opportunity for a library to fill the gap ...

[nkkollaw]

I wish there was a screenshot, just to gauge what it could do without installing.

[ktm5j]

Does it annoy anyone else when someone says something like "I wrote X in 50 lines of C"

And then the first non-comment line is: #include <X11/Xlib.h>

Which itself is over 4000 lines and includes tons more code.. It's a pretty meaningless metric.

[wtallis]

Writing X in 50 lines is almost always a statement more about the ecosystem X exists in than about the cleverness of the author of X. This headline tells us that the building a window manager can be done almost entirely with code that's already part of the window system, and requiring very little new code to achieve basic functionality.

[squarefoot]

I'm a lot more annoyed by programs requiring entire desktop environments such as Gnome or, even worse, KDE to do things which would be perfectly doable without that dependency. Those 50 lines probably won't become most people's favorite WM, but could be among the best places to look how to start writing one.

[AboutTheWhisles]

I think it depends on what the dependency actually is. Here it is expected that you would include this header.

When someone does a python one liner that just calls a library or something that relies on boost, the point is lost for anyone hoping to have a minimal example.

[justin66]

> Which itself is over 4000 lines and includes tons more code.. It's a pretty meaningless metric.

Hardly. Including standard libraries in the line count wouldn't mean much, unless you're the compiler.

Doing it this way lets you know how many lines are likely to have problems. Not to mention how much code the guy wrote.

[ChrisRR]

#include "TheRestOfTheFuckingOwl.h"

[StreamBright]

And all of this runs on a 1M+ loc kernel ;)

[segmondy]

Yeah, it annoys me when it's actually 50 lines of C code and it's more than 50 opcodes /s

[userbinator]

...as opposed to other window managers that are several orders of magnitude more code, also not including Xlib.h?

This "classic troll comment" appears with reasonable frequency in the demoscene: "your 4 kilobyte binary depends on gigabytes of OS libraries" --- and is countered the same way: "as opposed to a multi-gigabyte application also depending on same."

[proyb]

From what I understand, it's precisely a "wm" for Window manager and you'll see a list of other wm.

https://en.wikipedia.org/wiki/Comparison_of_X_window_manager...

Just as web developers could write x lines of code that run on any web browsers and engines.

[geofft]

Header files are generally declarations, not executable code, and for a program that's 50 lines long, it probably doesn't even have room to use all 4000 lines of declarations. It looks like it uses three structs and about three members of each of those structs, a half-dozen function calls, and a handful of constants, so you could write it without the include in under 100 lines.

A more meaningful objection is that you link with -lX11, which is a significant amount of actual code. But apart from "what about libc and the kernel" counterarguments, the X protocol is actually pretty straightforward - I'd bet you could write this with just socket syscalls in about as many lines of code, too. (Which is to say, an embedded system without libX11 could implement a window manager for a remote machine given just ~100 lines of C or similar and a TCP stack, and the TCP stack is only required because it's remote, anyway.)

[dig1]

With your reasoning, the one should use only kernel interrupts and go even without glibc; because even simple printf() would require thousands of lines pulled from stdio.h

X11 is part of the system, just like glibc...

[city41]

I disagree. I think most people distinguish between "end developer" code and libraries. I always find projects like this interesting and useful as they can be decent starting points to getting to know something.

[imode]

I feel that way when people write anything in a functional programming language.

"Here's this lovely new functional language!... written in Haskell, using Haskell's entire runtime as a basis."

[tree_of_item]

It's meaningful. X11 is a part of the structure of reality now, it's not going anywhere. Why can't you assume it?

[sillysaurus3]

It’s not meaningless though. Every language and platform has a stdlib. It’s interesting what can be done with them.