Xwm – a tiny XCB floating window manager | Hacker News Reader

Xwm – a tiny XCB floating window manager

github.com

69 pointsmcpcpc31 comments

Open articleView on HN

Possibly a slight naming conflict there, given, AFAIU, xwm was the first wm

https://web.archive.org/web/20020609220837/http://www.xwinma...

http://tech-insider.org/unix/research/acrobat/860201-a.pdf

After which there was xnwmm

http://www.mit.edu/afs.new/athena/system/x10r4/doc/mann/xnwm...

Then uwm

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

Oh man. I should have known, lol. Well I may need to consider a "rebranding". Thanks for pointing this out

Any other advice for checking for naming conflicts? I used github, google and repology.org and was excited when I saw no hits on the name. =S

If I google for list of X11 window managers "xwm", there's a reference in the first hit. The quotes around xwm are useful to screen out false positives.

ah. well my google-foo sucks. wikipedia even has an article. again, i appreciate you pointing this out. not sure what i will do yet though. :(

run a naming contest:

xwm2

x2wm

xxwm

newxwm

xcbwm

ywm

wwm

notxwm

nxwm

nwm

tinyxwm

txwm

txfwm

xcbfwm

oh god. commence operation “spam the random name generator”!

Taking a closer look at the original xwm, this project has long since been dead. i wonder if it would be fair to say the acronym itself could be used, as tribute to the original? or is that too confusing?

Go for “0xwm”, so it could be “Naught XWM”.

Naught ~ not. Sorry for the bad pun.

screenshot (in use): https://i.redd.it/ve0ra9qip7y51.png

Took heavy inspiration from dwm, bluewm, tinywm, lainwm and the likes to create what I would consider a minimally viable window manager solution. The project is C99 POSIX and MISRA compliant, which promotes portability, security and safety of the source.

I would say the target audience are those that spend most of their time staring at a single terminal and periodically need to jump into a GUI based application (e.g. web browser). There are many projects like this, but I am hoping to improve on previous ones by reducing the overall complexity (per the KISS principle) and improve upon documentation.

I am still developing my C programming skills, so all feedback is welcomed. =)

Enjoy!

> screenshot (in use): https://clbin.com/OEh1h

    $ HEAD https://clbin.com/OEh1h | grep Content-Type
    Content-Type: text/html; charset=UTF-8

The webserver is sending the image with the wrong content type, which makes some browsers (like mine) display the file as text. Viewing the file locally as a png works fine, but the browser only knows it's a png from the HTTP Content-Type header.

> I am hoping to improve ... reducing the overall complexity

I wish more projects had this goal.

    LDLIBS = -lm
    ALL_LDFLAGS = $(LDFLAGS) $(LIBS) -lxcb -lxcb-keysyms

The runtime deps - like the wm screenshot - are beautifully simple.

thanks! I spent quite a bit of time stripping out as many dependencies as i could.

will update the screenshot link shortly.

new link: https://i.redd.it/ve0ra9qip7y51.png

Love the simplicity, and it looks like this could serve as a great example for people wanting to write their own WM.

Might I suggest adding a link to a screenshot directly in the README? I personally have a weird fascination with window managers so I'm likely to check this out regardless, but a screenshot could go a long way in terms of generating interest. If you care about that sort of thing. :)

I see you have a minimalist IRC client as well. Funny, I've been meaning to get back into C specifically to toy around with the idea of writing my own WM and IRC client. Both projects look like great examples, thanks for sharing!

Thanks! It's been an almost 8mo journey learning C to get to this point. Ultimately it was the people that I interacted with and the user contributions that propelled me to make xwm.

I intentionally omitted a screenshot in the README as xwm, by itself, is not attractive. Also, really I wanted to leave ricing/tweak/patching to be entirely user contribution driven. I may consider, though, adding a directory in the patches (https://github.com/mcpcpc/xwm-patches) repo for user contributed screenshots though.

Different screenshot: https://clbin.com/iu9cJ

Out of curiosity how are you developing Xwm? Do you write/compile/run in a docker image?

In case of running/testing window manager on Linux there is Xephyr(1), which creates a brand new display (opened as a new windowed "app") that can be used without breaking the main $DISPLAY that comes with GNOME/KDE/XFCE/i3.

While ago, Julia Evans has published a blogpost about challenge to write own window manager [0]. Perhaps, you will find it interesting if would like to get know more about typical debugging tools for a window manager development.

[0]: https://jvns.ca/blog/2019/11/25/challenge--make-a-bouncy-win...

some interesting tips in that article. thanks for posting it!

Very good question! It's been a combination of techniques, but no Docker. I started my initial verification over a SSH/VNC session (e.g. x11vnc) on KISS Linux, which is what i personally run. Lately, I have been hosting various virtual machines and testing on multiple distribution snapshots (i.e. Debian, Arch, etc.)

I switch my process frequently as I move around quite a bit, making development work fairly tedious. I am sure that there is a better way, but this is what I found works for me at the moment.

I would appreciate a somewhat detailed comparison to evilwm and cwm (calmwm) that are also really clean and simple and have very similar features. What are the main differences (technical or philosophical) with these other programs?

Trying to put together a few example patches for xwm (i.e. focus borders and workspace). But once I get some bandwidth, I plan to provide some comparison data. =)

Just a quick glance at the source files for the two WMs you mentioned (along with a few others):

cwm-----> 6328 cloc, http://ix.io/2DGD

evilwm--> 3257 cloc, http://ix.io/2DGI

dwm-----> 2505 cloc, http://ix.io/2DGQ

xwm------> 301 cloc, http://ix.io/2DGE

tinywm---> 115 cloc, http://ix.io/2DGR

I think it would be unfair to compare xwm to either based on the sheer difference in cloc (10x+). A better comparison would be to dwm, bluewm, tinywm, lainwm or any of the smaller code-base projects.

From a philosophical standpoint, xwm is written using the XCB protocol while the other two are written using Xlib. The "X New Developer's Guide" is a good reference to understand the difference: https://www.x.org/wiki/guide/xlib-and-xcb/

From a sheer dependency standpoint, xwm has fewer than the rest. There are obvious drawbacks to this, but I intentionally left xwm as "barebones" as possible, to allow the community to expand, patch, tweak and modify. This is consistent with the Suckless Philosophy of programming (https://suckless.org/philosophy/), which is based on the Unix Philosophy of programming.

Additionally, I have opted not to have a run-time config file. Everyone seems to have a config file these days that is either placed in an obscure directory, "hidden" from plain site or cluttering my home directory. I hate config files (and they hate me). Not doing so forces the user to glimpse into the source which, to me, is a habit that all existing and new Unix users should be doing.

Amongst other things, I provide no out-of-box multi-monitor support, no menu bar, no title bars, no tab focus or or any other feature that a regular user would find essential. Instead, these features will be offered as patches, which the user must learn how to apply themselves.

I hope that information helps answer your question a bit. =)

Thanks! I'm going to try it. What made you go for xcb instead of (arguably simpler) xlib?

XCB is closer to the X protocol, making it significantly smaller and generally faster (and more responsive) than Xlib.

The argument of simplicity for source is relative to the API implementation. In this use case, the XCB API is the clear winner (imho).

Anybody ever associated very very lean window managers with constraint managers for the os/desktop layer ? we've seen a push on the browser side of things but it might very well benefit other parts.

http://scwm.sourceforge.net/

not updated in quite a long time, but still X :)

and scheme

Oh wow, it really is tiny -- about 300 lines of C. Great work!

Thanks! The challenge is keeping it from growing ;)

Can XWayland be used at the window manager layer?

No, XWayland explicitly breaks anything like that.

https://bbs.archlinux.org/viewtopic.php?id=185297

Probably doesn't work too well though.

Reply on news.ycombinator.com