
TinyWM – A tiny window manager in around 50 lines of C - LaSombra
http://incise.org/tinywm.html
======
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](https://news.ycombinator.com/item?id=17766249)

------
collinglass
I ported this to go for fun 3 years ago:
[https://github.com/collinglass/tinywm](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.

~~~
craftyguy
You can do this with i3 (or any tiling WM, I believe), since they
automatically maximize any window if it's the only one on the workspace.
Disable the panel/i3bar, and you would have what you seek. Start it with 'exec
i3' in .xinitrc and running 'xinit' on login.

~~~
jgtrosh
I have a work VM with a stripped out i3 that can't create new terminals other
than a startup terminal with tmux (which calls shutdown now on EOF); and it
can still do basic interaction with other new windows. This reduces problems
with VirtualBox X integration and makes the VM simple and like a terminal with
some X capabilities. I3 is really flexible for this kind of use case.

------
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](https://github.com/chneukirchen/cwm)
[1] [https://man.openbsd.org/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](https://dokk.org/manpages/cwm.1)

------
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.

~~~
squiggleblaz
It's already dying on X.

The new Gnome apps for instance don't respect standard interaction even when
the window manager is Gnome. (For instance, if a window has a modal dialog box
open, you can't move the window; I think I've also had issues with pushing
windows back despite this being a configuration option.)

If you use Chromium too, it doesn't respect your settings for where the
minimise/maximise/close etc buttons go until you right click somewhere and say
"let me forget that your developers think they're so special they have to
remind me i'm using your app every time i want to immerse myself".

Gnome people will probably say "it's a trivial bug which we will fix shortly".
But in reality it's intrinsic to the design. Now instead of picking an
application which does its job well and a window manager which does its job
well, you have to pick an application which manages its own windows well and
does its job well. All because someone thought it's prettier if title bars
have menu bars in them.

~~~
danmg
Commercial linux applications are hands down the worst in this regard. I don't
think I've used one yet that look and behaved well in terms of
focus/menus/clipboard/events/look-and-feel. Even ones made in QT are
statically linked and a different version from the distribution one so it
ignores all your preferences (I think that's the reason).

The push to make everything electron just means that everyone else is having
this problem now.

------
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](https://github.com/swaywm/wlroots) (note:
I am the maintainer of this software)

~~~
phkahler
>> With wlroots you could probably get pretty small, though, but you still
have to do rendering et al yourself...

Well yes and no. A wayland compositor has to blit the images of the
applications which need to draw themselves into buffers. At least that's my
understanding of it. The compositor isn't supposed to draw anything, it just
copies things to the frame buffer. I would hope a basic compositor could be
done with not too much code.

~~~
renox
> The compositor isn't supposed to draw anything, it just copies things to the
> frame buffer.

Depends, some of us thinks that server side decorations are better for
security, because otherwise a client can fake the look of another client.

~~~
phkahler
>> some of us thinks that server side decorations are better for security,
because otherwise a client can fake the look of another client.

If the decorations are done server-side then all applications will look the
same anyway.

Having said that, I think decorations probably are the job of the desktop
environment since those are the things that a user manipulates at that level
of abstraction. Moving, resizing, closing programs is a UI thing and an
application really shouldn't know where it is within the desktop environment.
That's actually a security concern IMHO.

~~~
renox
> If the decorations are done server-side then all applications will look the
> same anyway.

Uh? You should read about QubesOS..

------
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](https://github.com/wmutils) [1]
[https://github.com/tudurom/windowchef](https://github.com/tudurom/windowchef)
[2] [https://i.redd.it/ql1id3rocnq01.png](https://i.redd.it/ql1id3rocnq01.png)

~~~
drudru11
Very clean screenshot.

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

------
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....](https://github.com/rtyler/tinywm-
ada/blob/master/tinywm-xcb.c)

~~~
wangman
Wow 82 sloc. That just way too much bloat.

------
__s
This was a reference for me while initially developing nobox:
[https://github.com/serprex/nobox/blob/master/nobox.c](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.

~~~
jstarks
What about XCB?

~~~
wk_end
well, I said "effectively" didn't I...? ;)

XCB is, per wikipedia, "comparable, but slightly lower-level"; read that with
emphasis on "slightly". It's certainly better than xlib, and if you were to
write a real WM from scratch these days you should probably use it, but I
think bringing it up is sort of besides the point in this conversation: OP was
wondering if any sort of cheating was going on by including an X protocol
library, and the answer is "no": neither xlib nor XCB would be appreciably
providing any sort of abstraction around the concept of "X window manager".

------
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.

~~~
mbrumlow

      > Move windows interactively with Alt+Button1 drag (left mouse button)
      > Resize windows interactively with Alt+Button3 drag (right mouse button)
      > Raise windows with Alt+F1 (not high on usability I know, but I needed a keybinding in there somewhere)
      > Focus windows with the mouse pointer (X does this on its own)
    
    

You really don't need a screen shot. It is well described. Its 50 lines of
code, you can read them in a matter of seconds and determine it is simply your
programs plopped on the screen, no chrome, no borders, nothing, other than the
contents of the programs you started.

~~~
rsync
"You really don't need a screen shot."

...

"no borders"

Well, actually, I would like to see that ... which is to say, I would like to
see some GUI apps without borders, etc., since it is something I have never
seen before.

~~~
scbrg
Check out some screenshots of ratpoison, dwm or something similar. Granted,
dwm sticks a 1px border on windows by default, but it'll give you an idea of
how it looks.

[https://www.nongnu.org/ratpoison/](https://www.nongnu.org/ratpoison/)
[https://dwm.suckless.org/](https://dwm.suckless.org/)

------
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.

~~~
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.

~~~
ktm5j
This isn't just some standard library though, and what do you mean by
"wouldn't mean much, unless you're the compiler"? ...

The code in X11 libraries is infinitely closer to a window manager than what
this guy wrote. This is barely anything at all added to work that other people
did already.

~~~
detaro
And? It doesn't claim otherwise, and nicely shows off what's built in and what
a window manager does.

