[HN Gopher] TinyWM - A tiny window manager in around 50 lines of C
___________________________________________________________________
TinyWM - A tiny window manager in around 50 lines of C
Author : metadat
Score : 142 points
Date : 2022-10-25 14:20 UTC (8 hours ago)
(HTM) web link (incise.org)
(TXT) w3m dump (incise.org)
| rbanffy wrote:
| This kind of software really needs some screenshots.
| forgotpwd16 wrote:
| Not much to show. Running startx with .xinitrc containing:
| xterm & glxgears & exec /usr/bin/tinywm
|
| you get: https://files.catbox.moe/m0ejwr.png (pointer isn't
| shown but it's there)
| johannes1234321 wrote:
| From looking at the code there isn't much to screenshot. It
| doesn't seem to add decorations to the windows, just allows
| sizing and positioning. So a screenshot would show some windows
| from other applications without a frame. All value is in the
| source code showing principles.
|
| (I might have missed something)
| teucris wrote:
| The absence of frames or other elements is extremely valuable
| to understanding what the window manager does/does not have
| control over.
| skyyler wrote:
| It's like 50 lines, just imagine what it would look like :P
|
| It doesn't look like it's drawing any title bars or borders or
| decorations of any kind.
| teucris wrote:
| If I'm not already very familiar with X, how am I supposed to
| know that?
| mlyle wrote:
| The purpose of this code is not to provide a useful WM.
|
| It's to illustrate the minimum, in case you want to play
| with it and become very familiar with X.
| ranger_danger wrote:
| How to draw my own window decorations is exactly what I'd
| be interested in learning.
| Avshalom wrote:
| Twm, dwm or aewm might be good places to start for that
| guerrilla wrote:
| Every line of code has paragraphs of text describing what
| it does.
| Jasper_ wrote:
| Probably worth pointing out that while this will appear to work,
| it's certainly not ICCCM [0] compatible, so a lot of toolkits and
| applications that assume ICCCM compatibility will break.
|
| [0] https://www.x.org/releases/current/doc/xorg-
| docs/icccm/icccm... , one of the standards for how WMs and X11
| applications should communicate.
| auraham wrote:
| Wonder how hard could it be to add tiling support?
| Beltalowda wrote:
| You don't even strictly _need_ it in the WM, as you can resize
| windows from other programs, even shell script with xdotool
| etc, although xdotool /shell quickly becomes somewhat unwieldy
| I once wrote a "tiling WM" like this. It actually worked fairly
| well, and I kind of liked the modularity of it.
|
| At any rate, I dug up the old thing:
| https://pastebin.com/i91yD96F - I also had some other scripts
| to control window placement, movement, etc. I once planned to
| rewrite it to a "real" language and combine it with a "slightly
| less tiny wm" as a full release, but never really got around to
| it, and I also don't really use tiling any more (I just have
| one full-screen window all the time).
| ihatepython wrote:
| Not very hard as long as you don't care about drawing window
| frames.
| [deleted]
| mobilio wrote:
| Repost:
|
| https://news.ycombinator.com/item?id=994794
| https://news.ycombinator.com/item?id=17765446
| guenthert wrote:
| Can I make a wish? I would like a wm which sends SIGSTOP to
| processes which window I minimized and SIGCONT when I un-minimize
| it.
|
| For processes which use multiple windows, I'd be OK with all
| being minimized when one is to allow above functionality.
|
| There was a time when it was desirable to make room on the
| visible desktop while keeping long running processes running, but
| today we have lots of desktop real-estate and few legitimate long
| running processes, instead web pages leaching CPU cycles (I look
| at you, github!).
| TrisMcC wrote:
| From looking at the Issues on GitHub, it seems that someone
| ported it to XCB:
|
| https://github.com/rtyler/tinywm-ada/blob/master/tinywm-xcb....
| cestith wrote:
| Also, as the repo name suggests, the Xlib version is ported to
| Ada in there.
| quirino wrote:
| I used this as a starting point when playing around with writing
| my own WM, was very surprised with how little there is to it
| TillE wrote:
| Even without the comments, it's so great to have concise, fully
| functional sample code when you're trying to understand how
| something works.
|
| I love any time I can spend 2 minutes reading code instead of
| 20 minutes piecing together the basics from documentation.
| inetknght wrote:
| So... why C instead of at least C++ or an even better memory safe
| language?
| Beltalowda wrote:
| Because then it's no longer minimal. And as mentioned there's a
| Python version.
|
| This isn't a "real program", as such. It's a demo or "rainy
| Sunday fun to figure out a bit how X11 works".
| inetknght wrote:
| > _Because then it 's no longer minimal._
|
| C "might" be minimal but it brings with it a whole lot of
| dangerous baggage. Other languages can be just as minimal
| without the baggage.
|
| > _This isn 't a "real program", as such. It's a demo_
|
| I didn't mean to imply anything different. I was just curious
| why C was used in the modern day where we (all?) know that C
| is a language that _should not_ be used for demoing because
| less experienced devs will think they can use C too and
| continue to create dangerous code
| Beltalowda wrote:
| > why C was used in the modern day /*
| TinyWM is written by Nick Welch <mack@incise.org>, 2005.
| * * This software is in the public domain *
| and is provided AS IS, with NO WARRANTY. \*/
|
| > we (all?) know that C is a language that _should not_ be
| used for demoing because less experienced devs will think
| they can use C too and continue to create dangerous code
|
| That seems rather patronizing.
|
| I have no great love for C; it has sharp edges for sure,
| but it can be used just fine for a great many things even
| today. I've written a bunch of C programs because it's
| simple, straight-forward, "just works" (mostly), and I'm
| not writing OpenSSL or a network daemon so if I have an
| occasional buffer overflow it's not even a big deal.
| cestith wrote:
| The page linked offers a Python version calling into Python's
| Xlib binding python-xlib. It's the third code box down, after
| the bare C version and the heavily commented C version.
|
| Xlib itself is in C.
| chris_armstrong wrote:
| That's really minimal, even for x11: it doesn't even do
| reparenting and setting up window borders or xdamage/xfixes
| compositing
| tabtab wrote:
| It looks like X Window does most the of rendering, correct?
| (based on header: "#include <X11/Xlib.h>")
| avhon1 wrote:
| Yes, that's sorta fundamental to how X works. Window managers
| aren't at all responsible for drawing the contents of the
| windows.
| esjeon wrote:
| Wayland version of TinyWM:
| https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master...
| abhorrence wrote:
| I'm really keen to hear from someone who knows a bunch about X
| and WL to hear why there's such a huge difference in line count
| here. Is this analogous to OpenGL vs Vulkan where WL is a much
| lighter layer than X is?
| yamtaddle wrote:
| Yeah Wayland takes like 90% of the features of X and goes
| "you're on your own, window managers / desktop environments!"
| and if you complain they just say that's out of spec, working
| as intended, wontfix.
|
| It's like the exact opposite of what the Linux desktop
| needed.
| corndoge wrote:
| Links to further reading would be appreciated!
| zokier wrote:
| What Wayland really is a way for multiple applications to
| get access to and share dri/drm and evdev (kernel
| interfaces for putting stuff on screen and getting input
| respectively), nothing less and not much more. To enable
| that Wayland defines an IPC channel which is designed for
| extensibility, and there are some defined extensions to
| cover more desktop-like usecases (clipboards and
| whatnot). Some extensions are more widely supported by
| different compositors than others.
|
| For links, this docs page listing many (all?) wl
| extensions kinda gives you an idea what wayland core does
| not handle, and also what in general is available through
| wayland: https://wayland.app/protocols/
| yamtaddle wrote:
| https://wiki.gentoo.org/wiki/Wayland
|
| Found that pretty quickly and it doesn't go down a point-
| by-point feature comparison but gives you some idea of
| what's up in the "introduction" where it notes that
| Wayland doesn't include things like keymapping
| functionality, so that's all up to each compositor to
| implement. Excerpt:
|
| > From a user's point of view, Wayland is nothing more
| than a framework. In particular, Wayland itself does not
| implement any display server that should correspond to
| the Xorg server. In Wayland, compositors are display
| servers, implemented by various projects. A compositor
| also serves as X's window manager (and X's compositor).
|
| > This means users first have to choose a compositor, and
| via that compositor they "configure the server", i.e. set
| screen resolutions, input and video drivers options, etc.
|
| > [...]
|
| > Some lack of specification results in chaos more or
| less. For example one common complaint as of 2021 is that
| key remapping is absent in the Wayland protocol - in
| Wayland there is nothing that corresponds to xmodmap of
| X. Each compositor offers, if any, their own way to remap
| keys.
|
| > The situation however is not totally random - many
| compositors depend on the library "wlroots", which
| abstracts such common tasks, and is aimed to be
| impartial. First started as a subproject of the
| compositor Sway, it now is used by many compositors.
| Exceptions include mutter and KWin, i.e. GNOME and KDE,
| and Weston.
|
| TL;DR minor WM/DE projects have circled around wlroots as
| a life-raft to fill in the missing functionality, while
| major ones have gone their own way, resulting in
| extremely basic functionality potentially being wildly
| different (and having a different set of bugs and quirks
| and how-to-configure-and-use-it) depending on which
| compositor you're running, or even simply being absent on
| some.
|
| [EDIT]
|
| Unsurprisingly, Gentoo's cousin distro (if you will),
| Arch, has an even better page on it:
|
| https://wiki.archlinux.org/title/Wayland
|
| Note especially the part where it's possible for a given
| compositor not to work with certain graphics hardware,
| while others will. _That 's_ how little help Wayland
| gives to desktop environments and window managers. To get
| the equivalent of Xorg you'd have to get everyone to
| agree on a single fairly-big and featureful compositor
| and only use that.
|
| Or, good lord, look at the display manager support table.
| LOL.
| yoyohello13 wrote:
| Wayland is the protocol. It isn't analogous to X, so they
| really shouldn't be compared. Comparing Xorg to something
| like WLRoots makes more sense.
| FreeFull wrote:
| TinyWM doesn't include an X server implementation, while
| TinyWL is a full wayland compositor (although most of the
| heavy lifting is done by wlroots)
| nickstinemates wrote:
| Also not discussed - the wayland version implements a lot
| more features, comments, and boilerplate. The one in OP is
| 178 lines with comments and features basic window control.
| lampington wrote:
| It would be really interesting to see a Wayland version
| with equivalent functionally to the X one to get some idea
| of what the real difference is in complexity.
| tjdetwiler wrote:
| With x you're just bringing a window manager that plugs into
| the x-server. With wayland there's no standard 'window
| manager' plugin to arbitrary wayland servers. So the wayland
| example is doing more things (lots is handled by wlroots
| though).
| [deleted]
| [deleted]
___________________________________________________________________
(page generated 2022-10-25 23:00 UTC)