Mwm – The smallest usable X11 window manager | Hacker News Reader

Mwm – The smallest usable X11 window manager

github.com

203 pointsdaureg93 comments

This is the entire source:

    #include <X11/Xlib.h>
    #include <stdlib.h>

    #define stk(s)    XKeysymToKeycode(d, XStringToKeysym(s))
    #define on(_, x)  if (e.type == _) { x; }
    #define map(k, x) if (e.xkey.keycode == stk(k)) { x; }
    #define grab(...) const char *l[] = { __VA_ARGS__, 0 }; \
                        for (int i = 0; l[i]; i++) XGrabKey(d, stk(l[i]), Mod4Mask, r, 1, 1, 1);

    int main() {
      Display *d = XOpenDisplay(0); Window r = DefaultRootWindow(d); XEvent e;
      XSelectInput(d, r, SubstructureRedirectMask);
      grab("n", "q", "e");

      while (!XNextEvent (d, &e)) {
        on(ConfigureRequest, XMoveResizeWindow(d, e.xconfigure.window, 0, 0, e.xconfigure.width, e.xconfigure.height));
              on(MapRequest, XMapWindow(d, e.xmaprequest.window);
                            XSetInputFocus(d, e.xmaprequest.window, 2, 0));
                on(KeyPress, map("n", XCirculateSubwindowsUp(d, r); XSetInputFocus(d, e.xkey.window, 2, 0))
                            map("q", XKillClient(d, e.xkey.subwindow))
                            map("e", system("dmenu_run &")));
      }
    }

I have to say, I'm not usually a huge fan of C macros, but it works here so well, it feels so elegant and clean somehow.

Is it really that much better than this:

  #include <X11/Xlib.h>
  #include <stdlib.h>
  
  int GetKeyCode(Display* d, char* s)
  {
      return XKeysymToKeycode(d, XStringToKeysym(s));
  }
  
  int main()
  {
      Display* d = XOpenDisplay(0);
      Window r = DefaultRootWindow(d);
      XSelectInput(d, r, SubstructureRedirectMask);
  
      XGrabKey(d, GetKeyCode(d, "n"), Mod4Mask, r, 1, 1, 1);
      XGrabKey(d, GetKeyCode(d, "q"), Mod4Mask, r, 1, 1, 1);
      XGrabKey(d, GetKeyCode(d, "e"), Mod4Mask, r, 1, 1, 1);
  
      XEvent e;
      while (!XNextEvent(d, &e)) {
          switch (e.type) {
          case ConfigureRequest:
              XMoveResizeWindow(d, e.xconfigure.window, 0, 0, e.xconfigure.width, e.xconfigure.height);
              break;
          case MapRequest:
              XMapWindow(d, e.xmaprequest.window);
              break;
          case KeyPress:
              if (e.xkey.keycode == GetKeyCode(d, "n")) {
                  XCirculateSubwindowsUp(d, r);
                  XSetInputFocus(d, e.xkey.window, 2, 0);
              }
              if (e.xkey.keycode == GetKeyCode(d, "q"))
                  XKillClient(d, e.xkey.subwindow);
              if (e.xkey.keycode == GetKeyCode(d, "e"))
                  system("dmenu_run &");
          }
      }
  }

Just for fun I reformatted it minimally in the conservative way I write code that is intended to be easy to read and understand to improve the odds of future contributors (or future me) introducing a bug in it due to misunderstanding it.

It's painfully verbose but I think it's worth it considering that we're in 2025 and we're not limited to one character variable names.

https://gist.github.com/leonardo-albertovich/984fff0825ff8fe...

Sorry but you didn't just reformatted it, you added new variables and return statements that were not in the original code (and even introduced bugs like row 41).

As of short variable names, I'd argue that they are actually more readable than long ones when they're the iterator of a loop:

  while... XNextEvent(... &e)

What else can "e" stand for in the body of this loop?

Longer lifetimes and not-as-obvious scopes do deserve longer names.

Finally, I strongly dislike this kind of reversed conditions:

  if (const == var)

To paraphrase your own words, we're in 2025 and we should not be limited by our fear of forgetting one "=".

Oh no, I accidentally duplicated a function call while quickly rewriting the code for fun, what a terrible sin! (as a side note, I didn't even compile the code but I after quick check I don't see any notes on the man page that suggest that the accidental spurious repeated call could cause a problem)

I understand that you might not like that style but I think you're comming a bit too strong on this, especially considering how carefully I worded my message in terms of not hurting any feeling and being clear about this being MY preference.

I guess I shouldn't probably even answer but it saddens me and makes me a bit angry to get a reminder of why I don't usually participate in social media.

It was not my intention to make you sad or angry. I assure you that I have nothing against who uses a different coding style than mine. But consider that, just like you, I too have the right to tell the world what my preference is. Should I have softened my post with more "IMHO", "I feel", "my taste"? Probably, and I apologize.

Please don't stop participating in social media just because a halfwit like me hasn't agree with you once!

You know it's not about the disagreement, it's about that toxic need to be a smart-ass that's so prevalent in social media (including this platform).

I would've loved to engage in a conversation about coding styles such as MISRA, CERTs or even the small tweaks such as the one that offended you so deeply but you wasted the opportunity to engage in a constructive convesartion and instead chose to nitpick the "reformatting" thing (seriously, I just moved things around slightly, it's the same thing) or the nothing-burger "bug"...

I don't know, maybe I misinterpreted you and if that's the case then I apologize but when I saw that code and felt the urge to play/doodle I thought it could be a fun way to connect with someone over something silly and I just got disappointed.

I think this is more readable than with macros, but it might be a preference.

It's also 50 bytes longer than the original. More LOC only because my Vim formats on save.

Whenever somebody comes up with some big brain idea with macros, ORMs, DSLs, 180 IQ templates, language extensions that even Haskell nerds would say are too much, there's a good chance that the grugbrained version is just as readable, just as concise without going against the language.

I'm this close to go completely nuts with this industry and commit to full butlerian jihad against anybody who goes higher in abstraction than ANSI C.

Beware! That's the DSL trap.

It works here so well because it's limited to 20 lines and each macro does exactly what it needs to for the problem at hand.

Take that DSL and use it over a year to write a bunch of code to do normal things as your app grows into its problem domain and spills over into a few more, and it melts. New developers will show up to onboard to your and be like "WTF is this 'on()' thing I'm looking at all over the place, and why isn't it used over here?!". Some enterprising developer will introduce "map2()" to indirect based on keysym and not keycode, etc...

Domain Specific Languages are a mistake, almost every time they're used. And the only exceptions are the ones that grow into first class languages for well-defined problem areas (I'm thinking about things like VHDL or Mathematica here), and even there they tend not to be that much better than well-crafted domain-specific APIs in true programming languages (think numpy, pytorch, et. al.)

DSLs: Just say no.

there really isn't a fundamental difference between DSLs and libraries for the points that you brought up. where it really starts to get sketchy is when you do really funny things with the base syntax (looking at you lisp and rust). if not well thought out they can be fragile, confusing, and a real burden for new contributors.

I guess here's a question - do you consider regex libraries to be DSLs?

Interestingly I'd say a regular expression is absolutely not a DSL. It's sort of the opposite. A DSL is a tightly crafted interface for the configuration needed to support solutions to one somewhat unique problem. And the "trap" above is that the fact that the problem area is narrow means that only experts will really understand the DSL.

A regex is a tool implementing a solution (albeit a tightly crafted one) to an extremely broad set of problem areas. I mean, sure, in some sense it's a "DSL for string matching", but that doesn't really capture the essence of the DSL trap mentioned above. I mean, almost everyone needs string matching. So there's no trap: basically everyone knows regex syntax, even if they like to complain about it.

personally, I'd only consider a DSL to be good and useful if it can be implemented in different ways/languages, etc... It's not good if a DSL is language specific leaky abstraction.

Regex is a good example of a DSL.

Yeah exactly, this is why I stopped liking DSLs about 15 years ago, shortly after using Ruby extensively (probably not a coincidence) and converting to Clojure, where there was a large movement away from macros despite it being lisp. They're good in very isolated situations, and only when designed very carefully. This wm is quite possibly one of them; if you need more complexity than the macros here allow, and adding/changing macros only makes it worse, just use another wm.

This is slightly bigger version I wrote around 13 years ago. :)

https://github.com/savitasinghvit/piwm/blob/master/piwm.c

That macro usage is sublime. Bravo!

I wish things were as easy as they were with X11. Being able to ssh into a box and “export DISPLAY=192.168.0.7:0.0” then start an app and have it show up locally is just magical.

Your X network traffic would be clear text over the network if you did it this way.

Instead, you should "ssh -x" or "ssh -y" to pull the traffic over the ssh encrypted channel.

The -y option should be used with caution; read the docs.

> Your X network traffic would be clear text over the network if you did it this way.

that's exactly what I want on my local home network

You will also need to xhost +(host) which has its own problems.

It's capital -X and -Y

-x disables X11 forwarding.

Whoops.

Yeah, the days of remote displaying unwanted adult content on other computers on university lab for anyone clueless about xhost command, as teenagers do.

We had a bright future in the past.

Something tells me modern remote access tools that use video codecs are much more performant than SSH + X forwarding when dealing with resolutions and desktop effects we use today.

You mean a kind of "Spectres of Marx", Jacques Derrida, 1993, hauntology type thing?

There's waypipe.

This still works if X11 is installed on the remote. I have a remote that runs Wayland locally, and I run Wayland in the client machine as well, but I have X11 installed on the remote and X11 forwarding still works, it just opens the remote application in an XWayland window inside the local Wayland session. No biggie

For now

While this leaves a lot to be desired as a window manager, it illustrates one of my main gripes about the Wayland ecosystem: By effectively bundling the window manager and X server, it makes it much harder for more niche/experimental window managers to come about and stay alive. Even with things like wlroots, you have to invest a lot more work to get even the basics working that X11 will give you for free.

True; but a counterargument is that the _display protocol_ is not the right abstraction layer for decoupling window management from the display server. There is nothing stopping someone from writing a batteries-included wlroots-like library where the only piece you need to write is the window management and input handling, or even an entire Wayland compositor that farms these pieces out to an embedded scripting runtime.

But even then, I think we have rose-tinted glasses on when it comes to writing an X11 WM that actually works, because X11 does not actually give much for free. ICCCM is the glue that makes window management work, and it is a complete inversion of "mechanism, not policy" that defines the X11 protocol. It also comes in at 60-odd pages in PDF form: https://www.x.org/docs/ICCCM/icccm.pdf

For an example, X11 does not specify how copy-and-paste should work between applications; that's all ICCCM.

Copy&paste between apps should work just fine using this window manager.

I have not tried mwm but use my own 100 line C window manager and I can copy and paste without issue.

Wayland will take 20 more years before it can dethrone X11. And even then we will mostly run X11 apps on XWayland.

I'm sorry for not making it more clear, but that was just an example of something left unspecified by the X11 core protocol but instead defined in a standard convention.

An example that matters for window managers would be complex window reparenting policies or input grabs, but that's a little less descriptive of the core concept I was trying to get across.

We may not always have Paris, but we will always have XRotateBuffers.

https://tronche.com/gui/x/xlib/utilities/XRotateBuffers.html

> Wayland will take 20 more years before it can dethrone X11. And even then we will mostly run X11 apps on XWayland.

And yet RedHat/Fedora and Ubuntu, as well as GNOME, are leading the charge to drop X support in the next release; KDE as of V7. It may take 20 years for Wayland to match X's capabilities, but it looks like the guillotine has already been rolled out.

A more conspiratorial person than I could be led to think that RedHat is actively working against the viability of a free software desktop, but of course that's nonsense, because they're helping the cause by forcing all resources to be focused on one target at the expense of near-term usability. And the XLibre crowd also aren't controlled opposition intended to weaponize the culture war and make people associate X with fascism, that's just nonsense some idiot cooked up to stir shit.

> because they're helping the cause by forcing all resources to be focused on one target

This might work for company-backed projects but not for OSS enthusiasts and power users - they will leave for greener pastures. For example, Linux Mint lives off the manpower that GNOME 3 drove away, Void and Alpine Linux live off the manpower that systemd drove away. There will be some ecosystem that will live off the manpower that Wayland drives away.

https://www.donhopkins.com/home/catalog/unix-haters/x-window...

Window Manager Flames, by Don Hopkins

The ICCCM Sucks

The ICCCM, abbreviated I39L, sucks. I39L is a hash for the acronymic expansion of ICCCM for "Inter-Client Communication Conventions Manual". Please read it if you don't believe me that it sucks! It really does. However, we must live with it. But how???

[...]

> Even with things like wlroots, you have to invest a lot more work to get even the basics working that X11 will give you for free.

Like what?

A few years ago I copied the wlroots example, simplified it to less than 1000 LoC and then did some of my own modifications and additions like workspaces. And this side-project was done in less than a week on my spare time.

YAGN more experimental/niche window managers. Windows and macOS get by fine on one apiece, in fact their desktop story is better because their WM and toolkit is standardized.

The developers of Wayland (who are identical to the developers of Xorg) aspire to more of a Windows/Mac-like ecosystem for Linux, in which standardization, performance, and support for modern graphics hardware without hacks or workarounds are prioritized over proliferation of niche window managers and toolkits

Terrible window management is a huge reason I will not use Mac OS or Windows. I immediately lose so much productivity. I am coming up on my 30th year of using Linux, and I can't imagine moving to an OS with such limited window capabilities. No sloppy mouse focus? No always on top? No sticky windows? No marking windows as utility windows to skip alt-tab?

I watch my colleagues on Mac OS and Windows during peer programming, and am flabbergasted as they fumble around trying to find the right window.

I am interacting with my computers interface for 10+ hours every single day. I do not stare at a single application, but am constantly jumping between windows and tasks. The one size fits all approach is the same as the lowest common denominator approach, and it hinders people who need to do real work.

I have to use BetterTouchTool to make OSX usable. With BTT, OSX is awesome though. Much better than Windows.

Modern OSX does have always-on-top natively now btw.

Linux already has GNOME and KDE as solid mainstream platforms (which is already twice as good as MacOS/Windows), and it also already has Sway, Hyprland, Niri. If an idea is worth implementing, it gets implemented even with Wayland.

Windows is the epitome of bad window management. It's actually gotten worse as they've removed functionality over the years and broken other functionality. "Oh, you've got a modal window open? Now you can't even move the window that spawned it!" "Oh, you want to move this window to the top of the screen? Let me maximize that for you! Of course we're not going to let you disable that behavior..."

Microsoft got the Start Button/taskbar bit right in 1998 with the addition of the quicklaunch bar, although they keep trying to screw it up. But their window management has been abysmal since the beginning. If you use a large monitor (so you don't need to maximize everything) it's really painful.

> The developers of Wayland (who are identical to the developers of Xorg) aspire to more of a Windows/Mac-like ecosystem for Linux, in which standardization, performance, and support for modern graphics hardware without hacks or workarounds are prioritized over proliferation of niche window managers and toolkits

Is that why they arranged things to ensure that the Wayland world would always be split into GNOME, KDE, and everything else (in practice, wlroots)?

That issue is more naivety than anything else.

At least some ideas that were floated early on are deader than dead, like copy-paste as DBus Service

The few times I've had to use Windows and OS X for work has been sheer misery because of the poor window management.

More of a Windows/Mac-like ecosystem for Linux sounds like an awful threat.

This name conflicts with the original Motif Window Manager, part of OSF Motif. I don't know if mwm is found in modern Motif binary packages.

https://en.m.wikipedia.org/wiki/Motif_Window_Manager

The dtvwm eclipsed this in CDE.

MWM is included in modern Motif binary packages.

I think EMWM it's a better MWM. It even has options to make the menu sticky, a la Window Maker.

https://fastestcode.org/emwm.html

It's not CDE, but close. And some author wrote a tool to pin WindowMaker dockapps in a window, perfectly usable in a corner.

https://web.archive.org/web/20250105005119/https://luke8086....

I wouldn't mind using it on my n270 netbook, but a customized OpenBSD base's FVWM it's close enough to EMWM, minus the XFT fonts.

Heh, it's a preprocessor DSL:

    #define on(_, x)  if (e.type == _) { x; }
    #define map(k, x) if (e.xkey.keycode == stk(k)) { x; }
    #define grab(...) const char *l[] = { __VA_ARGS__, 0 }; \
                        for (int i = 0; l[i]; i++) XGrabKey(d, stk(l[i]), Mod4Mask, r, 1, 1, 1);

Stephen Bourne lives on! (Actually he's not dead, I just checked.)

> No title bars, no status bars, no buttons, no borders, no menus, etc.

> All windows are full-screen, just one is visible at any given time.

Oh, it's like cage ( https://github.com/cage-kiosk/cage ) for X11. I was wondering ex. how you'd even move windows around in that little code; the answer is "you don't":)

This one lets you move windows around:

https://github.com/mackstann/tinywm/blob/master/tinywm.c

No it's not. It lets you cycle through active windows with a hotkey, lets you close the current window, and launches dmenu to let you open more applications.

What's the point of the cage?

It's probably for building appliance/kiosk systems, though it's handy for anything where you just want to run a single application fullscreen.

If you want a single application fullscreen, you can just not start a window manager though.

In practice multiple applications get confused, and some don't support -geometry or equivalent.

One specific case I dealt with was Chrome/Chromium that provided all sorts of annoyances until we dropped in a minimal WM (back then it was awesomewm, I didn't know about cage or it didn't exist yet)

> applications get confused

Haven't had that yet. I thought of a single application the whole time, aka. kiosk, then it shouldn't matter.

In ye olden times, when most X11 applications understood "-geometry" and didn't try to do too much in absence of WM, things worked.

Chromium and possibly others (Chromium is just what I have personally dealt with) was confused about what did it mean to be fullscreen, and various other ideas regarding placing itself on screen.

I did success in making it work for a time, but it was problematic.

If you want something similar but more functional, check out https://www.nongnu.org/ratpoison/

> Most software today is crappy. Do you really need all the bells and whistles? Probably not.

I agree that most software today is bloated, but I wouldn't say crappy. There are legitimate reasons to choose bloat, for example using SDL or Electron to speed up development and have easier portability. But for some reason I do strongly enjoy writing and using minimalist software. That's why I removed C++, SDL and other libs from my app (hram.dev) and just used C, native Win32 APIs, and D3D, getting it down to 1.4mb and speeding up compilation a lot. So projects like this always appeal to me, and I love seeing different ways we can be minimalist without sacrificing too much functionality or convenience.

The best apps I've used have implementations for every OS and UI separately. Usually, everyone uses the easier route, but it will only be good enough, not the best. But again, now your app works only on Windows.

Yeah those apps were my inspiration: use the native UI and share logic as a lib.

I don't even have a Mac yet, so no point in shipping for that if I can't debug it.

If sales are good, I'd be glad to buy a cheap macbook off ebay and port it.

Even better if the library code is properly written, not only you can have multiple GUI frontends, you can make the CLI folks equally happy, and most of the code remains portable.

Naturally nowadays this is too much to ask for, so many ship the Chrome Application Platform instead.

It's a shame no one has figured out how we can get the flexibility of html/css/js in a way that is fast.

Tk?

Sadly very overlooked these days.

With ttk.

if you can elaborate a bit on a) flexibility b) fast

like the fellow commenter said, python might qualify as flexible, fast to code, and 'fast enough'

Python?

Is there a repo or page somewhere listing the mini-est stuff? Very cool here!

You can read and understand the code in a minute. Very creative.

How dare this person take `mwm`!!!

I have been using mwm (MOTIF) since 1991. Exact same configuration. It’s the perfect wm in my opinion. I’ve tried every major wm since, and I just can’t quit it. I do everything on the commandline, so I don’t need anything more than mwm. Who’s with me? Anyone? Anyone?

I ran it a bit back in the day. Wound up on FVWM since it supports MWM's features in addition to tons of other functionality.

These days I use KDE 'cause I'm lazy and it has decent customization options. It won't quite do what FVWM would, but it's in the right ballpark for me.

> Mwm – The smallest usable X11 window manager

Usable ? And using a traditional name ? Why not name it GNOME or KDE ? Or better: Windows.

Not ICCCM compliant.

It does say,

> Not standards-compliant.

in the very opening list of (non)features.

How can you tell / what did you see that was missing for ICCCM compliance?

Is anything similar possible with Wayland?

Wayland is a protocol, X11 is both protocol and a library. X11 client has much less functionality than Wayland compositor. Writing Wayland compositor is usually done with wlroots library to handle barebone stuff, but it has its own flaws: https://inclem.net/2021/04/17/wayland/writing_a_wayland_comp...

This WM is too extreme but in linux desktop, the less GUI you use, the better.

It is smallest than twn or uwm though?

"usable" is very generous

If it had proper Alt+Tab... and maybe a full screen mode, it would be usable...

Change

  grab("n" ...
  map("n" ...

  grab("Tab" ...
  map("Tab" ...

The very essential things a window manager should let me do are:

Launch applications (which might create new windows). Switch between windows. Close windows.

That sounds like the people who grew up using nothing but a smartphone all their lives. I find that there's an entire new generation of developers (and likely users) who don't understand basic window management at all --- all they have on their huge monitors all the time is one maximised application. Meanwhile I have several dozen windows open, all of various sizes, and when they see it, they are surprised at how I can work in such an environment.

No, I would not consider something that can't do what even Windows 1.0 could (tiled, nonoverlapping windows) a "window manager".

My cwm setup with a keyboard it's like that, but with a far better approach.

~/.cwmrc:

https://termbin.com/3jrl

It has a border (2px/4px dep. on the mood), you can execute programs with autocomplete (win+a), search between open windows (win+s), resize/move them, close (win+q), move them to virtual tags (desktops) shift+win+1-4, and go to each of these tags (win+1-4).

Minimal but actually usable. And fast as hell. I don't even need a mouse, and my RSI plumetted once I came from Emacs for a experiment (yes, I always had Ctrl and CapsLock switched over), even with CWM.

I find your stance uneducated.

I use tiling vm fully (sway) and mostly work in single app full screen, one desktop per app, which is the least disruptive way possible to use a PC for work. You should try it.

It's stupid to have a huge monitor (or monitors) and then use only a tiny fraction of it. I don't need a little window showing a few lines of text to be any bigger than it needs to be.

You should try it.

I've used an Android phone plugged into a monitor before when I had nothing else. Doesn't work for anything but the most trivial of situations, which IMHO says just how much work you actually do and how much information you actually use in your work. I need to look at multiple documents simultaneously to compare and refer to them. Switching between windows all the time and trying to memorise what they showed for a second or two is a stupid inefficiency.

When you have scanning eyes, any window on-screen that you are currently not scanning is a waste of pixels. These pixels could display data from your focused window instead.

I don't need the "focused" window to be 32" big.

Agreed, but I'll often be looking at one window while typing into another.

Reply on news.ycombinator.com