Mwm – The smallest usable X11 window manager

Mwm – The smallest usable X11 window manager
github.com

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.

  #include 
  #include 
  
  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 &");
          }
      }
  }

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.