A long, long time ago -- but still quite some time after it stopped being (too) regularly maintained -- I emailed Matt Chapman to ask him to include my WM in the list. He never answered, thank God, that was my first piece of non-trivial X11 code and it was absolutely gruesome, I don't know what the hell I was thinking.
WindowMaker, then FVWM were my drugs. I used tiling window managers for a while, when my typical workstation was a laptop, but now that I have a large-ish screen (27") on a desktop they're pretty bad -- everything is either too wide to be useful, or too narrow. Ratpoison was definitely my favourite (I also use Emacs, figures...), but I liked wmii, too. By the time I ran into pwm I was hooked into Ratpoison :).
LXQT does its job for me these days. It's not the most polished but at least it doesn't go out of its way to make my desktop look and act like a tablet so I'm happy with it.
I've been toying with writing a Wayland compositor that does wmii-like tiling, but can also do proper floating window management, but I have to wait for things to settle on the Wayland front before writing anything that's useful...
Edit: whoever downvoted you clearly never had a few hours of fun on a Friday night tweaking FVWM only to find out it's 4 AM now and oh crap it's also Monday!
> Edit: whoever downvoted you clearly never had a few hours of fun on a Friday night tweaking FVWM only to find out it's 4 AM now and oh crap it's also Monday!
I'm still sorry about my FVWM config. It was almost perfect. I should search for it in backups.
so do I. Although I discovered it rather late - in 2004.
It's remarkable how configurable it is. I adopted some version of what this guy did:
https://www.youtube.com/watch?v=xdSgf-IykIo
to do "manual tiling". Also can't find anything modern that even remotely can compare.
Funny to think that writing a window manager once seemed like quite a good use of one's time. I wonder what today's equivalent is.
I still in theory maintain one of mine (wmx), and this thread just prompted me to go and fix a few warnings that newer compilers come up with. Egads, there's some grubby code in there.
Hey, I remember wmx! That was pretty fun actually! Back in my super-minimalist phase, right between WindowMaker and ratpoison, I actually used it for a while!
Oh gawd, I spent so much time looking at that site and searching for the "best" wm. As my main WM, I've used fvwm (which I think was the default on slackware back then), olvwm (since I was used to Sun Unix machines from a summer job...), afterstep/windowmaker (NeXT was cool), fluxbox, kde 1.x-3.x, xmonad.
Nowadays I'm just using gnome with pretty much default configs.
I've been using Awesome on Debian Stable for years. I haven't configured it very much, and I mostly use it to keep everything full screen all the time. I'm sure at some point the X Window System will be completely abandoned and I'll have to move on to something else, but I haven't figured out what that something else is, just yet.
Sway can pretty much replace awesome nowadays, so I'd encourage giving it a shot. You can even script around the way it does multi-monitor workspaces to make them work similarly to awesome (just bind your switching shortcuts to a script that asks sway with swaymsg which monitor is focused). Finding a solution to this is actually what allowed me to abandon X11 and awesome for good.
I then stopped faffing about with such things (after spending huge amounts of time getting configuration just so) and over the years started increasingly just to go with defaults for most things.
What's getting it even close to that high? Even allowing for more features and some serious bloat I'd expect modern Linux with XFCE to fit inside 250MB, not counting file cache and such.
I really wish the full potential of compositing window managers could have been fulfilled, instead of the tech behind them being used for mostly eye candy.
Here are two items that should be doable with compositing. First, when giving a presentation with an external monitor, I'd like to tag specific windows to be mirrored (and scaled, if appropriate) on the secondary monitor. That way I can still be messing with my instant messages or email in private (which you can't do if you are mirroring your whole screen), yet be able to easily work with content that the audience is also viewing (by no having to shift my head from my laptop screen up to the projector all the time). This would be similar to using online meeting software where you share specific windows.
The second item, that you can sort of do now but not cleanly, is have multiple mice and keyboards, so that a mouse that selects a given window gives its associated keyboard input focus to that window. While the other mouse/keyboard combo is working with a different window. This would be great for pair programming, especially with a multi-windowed shared buffer editor (like what Emacs can do).
You can do this now, with some editing in the X config file, but there is no indication on the screen which window currently is focused to which keyboard -- this can be accomplished with the WM changing the window border or title bar color as appropriate.
Malleability of certain display characteristics is an important feature (largely for accessibility reasons), eye-candy is just marketing and signaling.
While I understand not wanting any useless eye-candy for functional purposes, I think there is also pleasure derived by simply "looking at pretty things".
It does not need to involve any external motivations.
"Eye-candy" can be supportive of said malleability.
Inferring form what you wrote, I think your working definition of marketing is wrong. Maybe you can clarify what you mean by "marketing"?
I am also unsure what you mean with "signaling". If you mean communication with the user via visual cues, than I would say signaling is an important feature.
Eye-candy is important with many things made for humans, not just computer displays.
By "marketing" and "signaling", I mean ricing. People want their GUIs to look pretty mostly as a way to either sell them or express their fashion sense to others.
I feel like the sweet spot for malleability was Win95-era theming. You could adjust the color of everything, and the typeface of everything, and that was it.
What's up with this glorification of Win95 style UI?
It's objectively ugly. Everyone I know or have known, in my entire life, without question, thought so back then, and does so now.
I am just so, so puzzled by this I had to type out this comment. Ignoring functionality, accessibility and all that, does anyone actually think it looked aesthetically pleasing, and I don't mean that in a 20-years-after nostalgic vaporwave way? Why is there a sudden wave against things being allowed to look nice and pleasing to the eye?
I liked it, for one. Especially after win3.1 The 3D buttons were much better than the flat rectangles in vogue today.
The UI might not have been perfect, but they gave an interface that provided a decent feedback while getting out of the way if you wanted to get work done.
Now if this is against being allowed to look pleasing? That depends on what you are comparing against, of course. Next and osx i could live with equally well, i guess. Modern win10, otoh, should be shot.
But thats my opinion. Do on your PC whatever you want.
"Instead" refers to the exclusivity of eye candy. So I'd rather see additional features enabled instead of an exclusive focus on flaming or squigly windows. Both would be fine, but if I had to choose...
Ok, understood. There is a diminishing return with every additional feature. I have to have a use case for every feature, otherwise it is useless and only takes up resources. My maximum number of use cases is finite.
This sort of thing is extremely difficult on X, but very doable on Wayland. I've been thinking about putting broadcast/streaming functionality directly into a compositor, so that your presentations/scenes could be composited separately from your actual windows. Think OBS, but the components/layers of the presentation are Wayland surfaces, and vice-versa, the windows are layers of the presentation. In this sort of system, the compositing can easily happen on the GPU, and can be accelerated like any desktop compositing.
I myself have been wondering why no one has made something like a complete software A/V router for this. Plug the output of any application through filters, splitters, muxers, duplicators, whatever, and ultimately out via your chosen sinks. Represent the whole thing in a 2d flowchart like QjackCtl or something.
This is sort of what PipeWire is for, as far as I'm aware. The one advantage of a more monolithic approach (where most of the AV handling is done in the same way as ordinary desktop compositing) is that buffers that originated on the GPU don't need to leave it until very late in the process. If you're really careful, no buffers leave your GPU except encoded complete compositions.
> This sort of thing is extremely difficult on X, but very doable on Wayland.
I'd say it is the other way around. With Wayland you'd need buy-in from the entire stack since in Wayland everything needs to be implemented in the compositor. With X all you need is a compositor (not necessary even your window manager, it can be a separate compositor) that ignores the area of one monitor when compositing and instead renders duplicates of the tagged windows there. You can keep using everything else you were already using.
I'm not clear on how this would happen on wayland as I haven't done any development on it yet, but with X it would be tricky since the server still has the window hierarchy state for event routing etc.
If you simply mirrored redirected windows in triplicate all over the place in the compositor, it wouldn't magically make the window manager and X server aware of all those areas as being windows to manage and route events at. You'd just have these ghost windows that can't be directly interacted with as first-class windows.
> You'd just have these ghost windows that can't be directly interacted with as first-class windows.
But that is what the GP asked for, not full duplication.
Though if you want duplication it might be possible by creating a window over the duplicated area that the compositor does not render but still grabs all input events that are then forwarded to the original windows via XSendEvent.
> First, when giving a presentation with an external monitor, I'd like to tag specific windows to be mirrored (and scaled, if appropriate) on the secondary monitor. That way I can still be messing with my instant messages or email in private (which you can't do if you are mirroring your whole screen)
You could start another X server for the secondary display and drive it via vnc or something like that. It's a different approach, but checks most (all?) Of the boxes.
There are tiling solutions for most OSes, but unless you can get access to an API as low level as X, they tend to not be as good. Amethyst is admirable in many ways, but it's a far cry from i3. Amethyst also has to wrangle with issues such as certain windows just flat out ignoring it, which i3 -- due to how X works -- doesn't have to worry about. i3 is a rock solid tiling solution that pretty much 100% works, and Amethyst is unfortunately a patch on top of another window manager and so can often be clunky.
Currently it's just a Chrome extension. The Chrome windows API is pretty decent. I think this "window manager" will have plenty of limitations, but I also think it might just be good enough. In parallel I'm also poking at ash a little bit, but I doubt I'd be able to take on such a large project and actually succeed.
I used StumpWM for a while, but switched back to i3, although I miss controlling my WM with Common Lisp. If StumpWM could implement i3-like window management, I'd be in heaven.
Stump's static window frames is what's kept me using it for so long. I hate how i3 and other dynamic tiling WMs reshuffle and resize everything as soon as you open a new window.
However I'm currently trying w9wm again; I have a slightly-hacked version that I've used on and off for about a decade and it's always fun to return to.
Yeah, i3 is awesome. Sidenote: r/unixporn is probably one of my favorite subreddits, its where I discovered the capability of i3 and always go there for inspiration.
I was a long time Window Maker (not Windowmaker, the world's leading software for... something else) user for a long time as well, but finally jumped ship to boring old KDE.
It finally acquired most of the essential window management features of WMaker, such as Meta-R/L-Mouse to move or resize the window by clicking anywhere into it or shading windows.
However I still miss selecting multiple windows with a rubber band and then moving them to a different virtual desktop together, or the dock apps. I still can't find a proper widget which displays the network activity or something like wmforkplop to show the general system load.
I have a basic environment I take with me across distros and across time: Window Maker, xterm, zsh, and Emacs. I have configuration files for all of them, and the combination makes me fairly insensitive to distro as long as it has a reasonable package repository and dependency-tracking package management.
I was a long time KDE user, then went to light weight wm I switched around from fluxbox, openbox. Then I went to tiling window managers. Which is where I'm at today. I have a screen shot of my old xmonad setup.. http://i.imgur.com/c4HGAEs.png
But now I'm using i3, as managing haskell crap is kind of a pita.
Haven't the Xorg developers expressed interest in deprecating it? Sure, someone could take up the mantle to continue working on Xorg, but it sounds similar to staying on Python 2.
The Wayland developers are the Xorg developers. It's most of the same core people, so yes. they certainly want to move away from Xorg.
I'm not quite shore what the BSD people are planning. Do they plan on keeping a fork of Xorg or eventually trying to port Wayland to FreeBSD/OpenBSD/et. al.?
Unlike Python 2 not everyone among the Xorg developers want to drop it (e.g. Keith Packard doesn't seem very interested in Wayland). Also Xorg isn't really one thing, it is a bunch of different subprojects with the server being the one that is mostly referred to. Even if everything else stays exactly the same, the X server will still need to be updated since it also works as XWayland.
Finally unlike Python 2 vs 3 the difference between Xorg and Wayland is tremendous, so i can easily see people who will be willing to fork it to continue development.
> the X server will still need to be updated since it also works as XWayland.
No, it will not. Xwayland will likely be deprecated and removed in the coming years. The rationale being that nobody uses any Athena or Motif programs anymore and all of the toolkits that matter to modern desktops will have Wayland backends already.
Sure, and Linux will remove support for 32bit applications any time now :-].
Also since it got open sourced (properly), there are more people using Motif applications nowadays than 10 years ago. And there are other toolkits that target X outside of Athena and Motif.
And besides, "removed"? Removed from where? Xorg is just a historical name nowadays, what was called Xorg is a bunch of independent packages and the X server is a package by itself. The only way "removed" would apply here is removing the Wayland backend from the X server. Which isn't impossible, but after all the work that went into it, doesn't make sense.
This will be a no-go for many Nvidia users looking to use the proprietary video drivers and due to political/philospical differences it will likely never be supported.
I'll use KDE/gnome from time to time for very specific things, but I could never go back to using them generally. That being said, I always install KDE to get some of the tools, such as Konsole.
I used gnome2 for a while, then eventually moved to awesomewm when gnome-shell was announced, but I've settled on dwm as my wm of choice. It does what I want and nothing else.
lxde worked well for me and memory footprint is totally good.
still the GUI for embedded linux device is lacking, Android unifies that but it's more for phones loaded with a huge chunk of bloat-ware for other non-phone use cases.
I have been looking for embedded-linux-GUI for a long while, but I'm happy with gnome/lxde on Desktops.
I love the variety of styles and customizability. It’s really impressive to see some of the designs people have over at reddit.com/r/unixporn . I want to jump in but then realize how much of a time sink it can be.
I've used i3wm and quite liked it. Simple, efficient and easy to setup. I'd properly propose i3 for anyone wanting to taste what a tiling window manager is like. I don't think it's competitors are nearly as easily configurable but I only have experience with i3wm so I cannot say for sure.
To pharaphase Tuomo Valkonen (creator of the tiling window manager ion), most of these should not be called window managers since they make you manage the windows.
I use ratpoison and GNU screen.
These wikipedia lists can be quite helpful, even if they are often out of date and incomplete.
89 comments
[ 2.3 ms ] story [ 181 ms ] threadA long, long time ago -- but still quite some time after it stopped being (too) regularly maintained -- I emailed Matt Chapman to ask him to include my WM in the list. He never answered, thank God, that was my first piece of non-trivial X11 code and it was absolutely gruesome, I don't know what the hell I was thinking.
LXQT does its job for me these days. It's not the most polished but at least it doesn't go out of its way to make my desktop look and act like a tablet so I'm happy with it.
I've been toying with writing a Wayland compositor that does wmii-like tiling, but can also do proper floating window management, but I have to wait for things to settle on the Wayland front before writing anything that's useful...
Edit: whoever downvoted you clearly never had a few hours of fun on a Friday night tweaking FVWM only to find out it's 4 AM now and oh crap it's also Monday!
I'm still sorry about my FVWM config. It was almost perfect. I should search for it in backups.
https://en.wikipedia.org/wiki/Ion_(window_manager)
I still in theory maintain one of mine (wmx), and this thread just prompted me to go and fix a few warnings that newer compilers come up with. Egads, there's some grubby code in there.
Writing your own web framework?
Nowadays I'm just using gnome with pretty much default configs.
I use cwm now though because it just gets out of the way and does it’s job.
It has very few dependancies, it’s definitely one of the easier packages to build yourself.
twm -> olwm -> mwm
I then stopped faffing about with such things (after spending huge amounts of time getting configuration just so) and over the years started increasingly just to go with defaults for most things.
What's getting it even close to that high? Even allowing for more features and some serious bloat I'd expect modern Linux with XFCE to fit inside 250MB, not counting file cache and such.
Here are two items that should be doable with compositing. First, when giving a presentation with an external monitor, I'd like to tag specific windows to be mirrored (and scaled, if appropriate) on the secondary monitor. That way I can still be messing with my instant messages or email in private (which you can't do if you are mirroring your whole screen), yet be able to easily work with content that the audience is also viewing (by no having to shift my head from my laptop screen up to the projector all the time). This would be similar to using online meeting software where you share specific windows.
The second item, that you can sort of do now but not cleanly, is have multiple mice and keyboards, so that a mouse that selects a given window gives its associated keyboard input focus to that window. While the other mouse/keyboard combo is working with a different window. This would be great for pair programming, especially with a multi-windowed shared buffer editor (like what Emacs can do).
You can do this now, with some editing in the X config file, but there is no indication on the screen which window currently is focused to which keyboard -- this can be accomplished with the WM changing the window border or title bar color as appropriate.
Why "instead"? Best would be to have both. Eye candy is an important feature. No need to sacrifice one to get the other.
It does not need to involve any external motivations.
Inferring form what you wrote, I think your working definition of marketing is wrong. Maybe you can clarify what you mean by "marketing"?
I am also unsure what you mean with "signaling". If you mean communication with the user via visual cues, than I would say signaling is an important feature.
Eye-candy is important with many things made for humans, not just computer displays.
I feel like the sweet spot for malleability was Win95-era theming. You could adjust the color of everything, and the typeface of everything, and that was it.
I am just so, so puzzled by this I had to type out this comment. Ignoring functionality, accessibility and all that, does anyone actually think it looked aesthetically pleasing, and I don't mean that in a 20-years-after nostalgic vaporwave way? Why is there a sudden wave against things being allowed to look nice and pleasing to the eye?
The UI might not have been perfect, but they gave an interface that provided a decent feedback while getting out of the way if you wanted to get work done.
Now if this is against being allowed to look pleasing? That depends on what you are comparing against, of course. Next and osx i could live with equally well, i guess. Modern win10, otoh, should be shot.
But thats my opinion. Do on your PC whatever you want.
https://pipewire.org/
I'd say it is the other way around. With Wayland you'd need buy-in from the entire stack since in Wayland everything needs to be implemented in the compositor. With X all you need is a compositor (not necessary even your window manager, it can be a separate compositor) that ignores the area of one monitor when compositing and instead renders duplicates of the tagged windows there. You can keep using everything else you were already using.
If you simply mirrored redirected windows in triplicate all over the place in the compositor, it wouldn't magically make the window manager and X server aware of all those areas as being windows to manage and route events at. You'd just have these ghost windows that can't be directly interacted with as first-class windows.
But that is what the GP asked for, not full duplication.
Though if you want duplication it might be possible by creating a window over the duplicated area that the compositor does not render but still grabs all input events that are then forwarded to the original windows via XSendEvent.
You could start another X server for the secondary display and drive it via vnc or something like that. It's a different approach, but checks most (all?) Of the boxes.
I think it’s a shame you can’t get something like i3 on OSX or Windows. It’s a primary reason I stick to Linux.
I presume you mean more than just tiling? As Amethyst [1] gives you that on macOS.
[1] https://github.com/ianyh/Amethyst
This is neat! Are you writing this as some sort of Chrome Extension or forking Ash?
This extension is a window manager that mimics Amethyst for OSX: https://github.com/brockgr/chrometile
It can give an idea of what's possible with the chrome.windows API.
However I'm currently trying w9wm again; I have a slightly-hacked version that I've used on and off for about a decade and it's always fun to return to.
It finally acquired most of the essential window management features of WMaker, such as Meta-R/L-Mouse to move or resize the window by clicking anywhere into it or shading windows.
However I still miss selecting multiple windows with a rubber band and then moving them to a different virtual desktop together, or the dock apps. I still can't find a proper widget which displays the network activity or something like wmforkplop to show the general system load.
Only using 3 pages of RAM is pretty good
But now I'm using i3, as managing haskell crap is kind of a pita.
I'm not quite shore what the BSD people are planning. Do they plan on keeping a fork of Xorg or eventually trying to port Wayland to FreeBSD/OpenBSD/et. al.?
Finally unlike Python 2 vs 3 the difference between Xorg and Wayland is tremendous, so i can easily see people who will be willing to fork it to continue development.
No, it will not. Xwayland will likely be deprecated and removed in the coming years. The rationale being that nobody uses any Athena or Motif programs anymore and all of the toolkits that matter to modern desktops will have Wayland backends already.
Xwayland may kick around for really old apps but it will not be maintained at all and you will be expected to forward-port your software to Wayland.
But more likely, they will need to be run on some ancient OS or distro version and thus containerized or virtualized anyway.
Also since it got open sourced (properly), there are more people using Motif applications nowadays than 10 years ago. And there are other toolkits that target X outside of Athena and Motif.
And besides, "removed"? Removed from where? Xorg is just a historical name nowadays, what was called Xorg is a bunch of independent packages and the X server is a package by itself. The only way "removed" would apply here is removing the Wayland backend from the X server. Which isn't impossible, but after all the work that went into it, doesn't make sense.
I'll use KDE/gnome from time to time for very specific things, but I could never go back to using them generally. That being said, I always install KDE to get some of the tools, such as Konsole.
https://www.youtube.com/watch?v=ON0A1dsQOV0
still the GUI for embedded linux device is lacking, Android unifies that but it's more for phones loaded with a huge chunk of bloat-ware for other non-phone use cases.
I have been looking for embedded-linux-GUI for a long while, but I'm happy with gnome/lxde on Desktops.
I use ratpoison and GNU screen.
These wikipedia lists can be quite helpful, even if they are often out of date and incomplete.
So far quite a lot of work remains to bring them up to date.
(from the '90's anyway.)