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.
that's exactly what I want on my local home network
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.
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.
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???
[...]
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.
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
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.
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.
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)?
More of a Windows/Mac-like ecosystem for Linux sounds like an awful threat.
#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 &")));
}
}
#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 &");
}
}
}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...
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.
I guess here's a question - do you consider regex libraries to be DSLs?
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.
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.
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".
~/.cwmrc:
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 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.
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.
> 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":)
https://en.m.wikipedia.org/wiki/Motif_Window_Manager
The dtvwm eclipsed this in CDE.
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.
> Not standards-compliant.
in the very opening list of (non)features.
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?
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.
#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);
Usable ? And using a traditional name ? Why not name it GNOME or KDE ? Or better: Windows.