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.)
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.
Yeah, the days of remote displaying unwanted adult content on other computers on university lab for anyone clueless about xhost command, as teenagers do.
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
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.
> 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
> 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":)
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.
> 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.
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.
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...
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".
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.
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.
90s_dev|7 months ago
qsort|7 months ago
ajross|7 months ago
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.
illegalmemory|7 months ago
https://github.com/savitasinghvit/piwm/blob/master/piwm.c
klaussilveira|7 months ago
trollied|7 months ago
chasil|7 months ago
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.
pjmlp|7 months ago
supportengineer|7 months ago
SbEpUBz2|7 months ago
dingnuts|7 months ago
ahlCVA|7 months ago
tadfisher|7 months ago
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.
zenolijo|7 months ago
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.
bitwize|7 months ago
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
chasil|7 months ago
https://en.m.wikipedia.org/wiki/Motif_Window_Manager
The dtvwm eclipsed this in CDE.
zshrc|7 months ago
ajross|7 months ago
yjftsjthsd-h|7 months ago
> 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":)
vidarh|7 months ago
https://github.com/mackstann/tinywm/blob/master/tinywm.c
chmod775|7 months ago
mosquitobiten|7 months ago
int_19h|7 months ago
90s_dev|7 months ago
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.
gen2brain|7 months ago
jjrh|7 months ago
throwaway328|7 months ago
adxl|7 months ago
scoreandmore|7 months ago
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?
spauldo|7 months ago
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.
hulitu|7 months ago
Usable ? And using a traditional name ? Why not name it GNOME or KDE ? Or better: Windows.
teddyh|7 months ago
yjftsjthsd-h|7 months ago
> Not standards-compliant.
in the very opening list of (non)features.
blueflow|7 months ago
neoden|7 months ago
ivanjermakov|7 months ago
newlisp|7 months ago
pjmlp|7 months ago
rithikrolex|7 months ago
[deleted]
poly2it|7 months ago
rs_rs_rs_rs_rs|7 months ago
silon42|7 months ago
userbinator|7 months ago
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".
anthk|7 months ago
~/.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.
0points|7 months ago
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.
blueflow|7 months ago