XMonad – The Automated Tiling WM
xmonad.org
xmonad.org
But, I was an i3wm user, and now it’s hard to imagine going back to X11. I run SwayWM on NixOS and using Linux any other way feels archaic now. Yes, I do genuinely understand how that seems absolutely ridiculous, but honestly, it does. Other than the occasional stability issue or bug, it really feels like the future is arriving: smooth rendering, predictable latency, hardly an imperfect frame, heterogeneous DPI with no effort, no need to string along GNOME or KDE services to configure input devices or manage displays, yet to experience any problems with sleep/resume, and with NixOS, a simple, centrally managed configuration for my whole OS (including Sway) and any patches, git-versioned. It isn’t perfect, but it is almost as good as promised. I just recently setup a new desktop by grabbing a recent NixOS USB stick, formatting the drives, git cloning my configs, and running the installer, and one reboot later I was in my environment with Sway, all of my applications, my configuration…
I’ve tried versioning my dotfiles before, but this seemed to both be more tedious and still not really accomplish what I wanted. My desktops and laptops are single user, so I can just use NixOS to manage system-wide configs instead and get 99% of what I actually wanted.
I’ve digressed a bit into stuff very unrelated to WMs, but the software around your WM is important when dealing with tiling WMs. Nobody wants a bespoke pile of complex configurations that could break on an upgrade without warning, and that has never been more important than with minimal WMs.
I have a sway/linux laptop from 2017 and a 2020 intel macbook pro. The hardware in the mac is nearly double the real world performance but the way the windows move with yabai feels incredibly slow and janky.
And the hotkeys are a pain in the arse compared to sway, I resorted to skhd and karabiner elements working cooperatively.
Notes:
yabai needs a scripting addition, and new versions of it seem to need you to manually reload it.
skhd and yabai both need "accessability" access in settings, new versions seem to need to be re-added (and the old entry that you approved before gets a "No icon" icon which makes it feel jank and confusing, like, you think you enabled accessibility but it complains)
yabai also needs you to disable system integrity protections.
And added to that: most macOS windows can't be resized, so they fall off the screen or leave half a screen empty.
Honestly it was not a pleasant experience and was one of the main reasons I went back to linux, despite the subpar software support of things like zoom (which doesn't allow screensharing on wayland)
I really want it to work because otherwise macos is unusable for me
I've found that overlapping windows makes sense for "gui" like applications: Half of the screen is too small for a web browser or a graphical email program or an IDE.
So these days I make do with a program that allows me to use keyboard shortcuts to move the current window to a specific position and size (different shortcuts for different positions and sizes). In this way, I spend very little time moving windows around, as I just need to hit the key for the position I want.
Also, I don't tend to move windows around, e.g. my terminal is always at the same spot, and my browser is also always at the same spot (different than the terminal). So I don't have to touch a window often.
As a maintainer of xmonad upstream, I'm watching the waymonad project to see where it goes, but I have some concerns about its architecture which I'd love to see addressed before we'd officially endorse people to try switching. This is a copy of a message I sent to fellow xmonad developers a couple months ago:
> We should certainly take a look sooner or later. From a quick glance, I have some concerns about the general design of it:
> It's a compositor and window-manager in one. This is typical for Wayland, but there are lots of disadvantages:
> * Restarting the WM is just like restarting X: session over. Unacceptable for xmonad/waymonad, as we don't reload config, we recompile and restart. Someone is apparently working on making Wayland compositors restartable, in general: https://indico.freedesktop.org/event/1/contributions/20/, though.
> * Another consequence of the WM and compositor being one is that they share memory leaks and GC pauses and signal handlers and whatnot. As much as I love Haskell, I'd prefer frames from an FPS shooter to be presented on screen by something else. Oh and did I mention the compositor/WM also handles input, making any GC pauses doubly painful?
> * Aside from operational issues, this also means all of that needs to be implemented. There's https://github.com/swaywm/wlroots/ (used by waymonad), a library that supposedly lets individual Wayland compositors implement less code, but it doesn't seem to be nowhere near what X gives us: we take care of window management and all the input/output handling is taken care of by other tools with their own configuration and tools. It simply doesn't seem to work that way in the Wayland world. There are other options like implementing a shell plugin for Weston, or possibly other libraries, I don't really understand the landscape.
> I may be wrong on some of these, as I didn't actually try to compile and run the thing.
> Anyway, I am convinced it'd be best if the compositor and WM were separate processes, ideally maintained by separate teams. You know, that old “do one thing and do it well” philosophy. And I have no idea how difficult would it be to make things work this way. If someone were to work on this, discovering the answer to this question would be one the first things to do.
I should probably clarify the wlroots handling IO thing: what I meant is that with Xorg, there are command-line tools like setxkbmap, xinput, xset, xmodmap, xcape, xrandr, autorandr and possibly others that a user can use to interact with the X server and tweak stuff, and from what I understand these don't have equivalents in the Wayland world that would work across WMs/compositors. I could be wrong, though, perhaps wlroots does have a standard protocol for such things and such tools already exist?
I'm the (mostly negligent) original author of waymonad.
Minor GC stalls are not an issue for reasonable framerates right now. Major stalls are in the order of a single frame. Which I considered acceptable, but YMMV.
I fully agree on the issue with restarting. I had some ideas about how to improve that, but never got around to doing any of that. wlroots was my choice, because I like the guys and worked with them on the project. Other libraries (most relevant probably libweston) are a bit more "fully featured" but also slightly less flexible.
Can you perhaps share some of those ideas? Might be something I haven't thought about. :-)
> wlroots was my choice, because I like the guys and worked with them on the project. Other libraries (most relevant probably libweston) are a bit more "fully featured" but also slightly less flexible.
Is that still the case today? I mean, I haven't really spent any considerable time researching the Wayland landscape, but I was under the impression that wlroots gained considerable momentum in recent years while weston is still just the reference compositor, but not really used in any well-known Wayland compositor.
My main idea around persistance was a wrapper core code, that loads the higher level library. So we could switch out the library as object inside the main code. At the same time, I'd have used this chance to experiment with hot-path loops that avoid the Haskell runtime, but run in native code. To avoid the previously mentioned GC stalls.
Though in practice, that gets closer to the X model, where we split the display server and window manager with a proper API. We'd still have more control on what we want async and what we want sync. And it'd be up to experimenting how much of the display manager should be exposed as library functions or just driven from the outside.
Other ideas like serializing state and passing that in some way could work to some degree, but are probably not worth it. Maybe with some help from CRIU stuff, but I'm unsure about OS portability of that.
In general, the big learning I'd like people to take, which is mostly unrelated: don't try to do multi-seat. xmonad has a neat design, and the attempt to add multi-seat broke so much stuff. It's not worth it for a probably <.1% feature.
Out of those persistance ideas, I'm still very much in favor of simply separating the compositor/WM into separate unix processes. Feels like the right thing to do.
I thought wayland specifically made input/output configuration completely the DE's problem?
Using NixOS to manage your whole system, on the other hand, I don't think I'll ever get behind. Maintaining reproducible builds of my system, while being nice to have, doesn't really solve any problem that I actually have. On the other hand, it introduced a myriad of problems that plagued me on a regular basis before I switched away from it.
The first problem I had was that it added steps to a number of tasks I had on a regular basis. For example, updating or adding new extensions to VS code. Because NixOS is immutable, you don't get to benefit from just running a single update or install command within VS code like you would on a normal system. It becomes an annoying series of steps you have to carry out for each operation, all in the name of being convenient to hypothetically down the line. Multiply this by all the tools you use and it gets tiresome.
The other issue is that you raise the barrier of entry for every new piece of technology you want to experiment with. Now, in addition to learning how to use any tooling involved with the ecosystem, you have to figure out how to get it to play nicely with Nix. This works very well for some ecosystems, like Haskell, and not well at all for others. I was just getting started with Android development at the time, and just when I thought I had it working nicely with Nix, I would run into a new problem that would need investigation and band-aids.
I wish NixOS was more convenient to use than it was in my experience, because it's nice when it works well. But in my case it created more problems than it solved.
I don’t have issues with my configuration breaking. My NixOS configuration hasn’t broken due to updates in months.
I will say that some stuff is not easily encapsulated in Nix. Of course, you could always use virtual machines or Docker as an escape hatch. I’ve found this to be a fairly good solution in the somewhat rare event I need it.
My biggest problem with NixOS is the complexity. Nixpkgs is maintenance hell, and the Nix filesystem is so different from standard UNIX-likes that a lot of software plays kinda weirdly with it.
The real game changer is definitely the reproducibility though. At first, it seems useful for software development, but trust me, if you get deep enough in it is way more important for system management. If an upgrade does break, being able to rollback at boot is nice. But what is much nicer is simply the feeling of safety I have going in extreme tangents. I can try setting up Pipewire as my system audio daemon, and if I don’t like it, I can revert it like nothing ever happened. If I run into a bug that has a reasonably good patch stuck in code review hell, I can pull it into my local setup with overlays, replaceDependency and fetchpatch. Setting up IOMMU PCI-e forwarding to a VM is pretty hard, and it sucks that the configuration is basically stored in no specific place, not to mention having to memorize everything you touched to get there; on NixOS, this relatively arduous task was reduced down to about 30 lines of Nix combined with finding some IDs for my secondary GPU. Everyone knows that Linux has some serious super powers if you can exploit them; it is truly crazy what Linux is really capable of. With NixOS, I feel like I’ve gotten a lot better at utilizing the super powers Linux has to offer.
I just can’t go back to Debian or Arch after this, I’ve tried. Maybe NixOS isn’t the final answer, but I’ll be damned if it’s not a preview of the future.
This was my train of thought at the time, too. But now you're just using software normally, but with an extra step, and no NixOS benefit.
> I will say that some stuff is not easily encapsulated in Nix. Of course, you could always use virtual machines or Docker as an escape hatch. I’ve found this to be a fairly good solution in the somewhat rare event I need it.
It's true, escape hatches exist. But they are solutions to problems you are _creating by using nixos_, which did not occur on a normal FHS system, and require time and energy investments to solve them. And those problems are landmines lurking in every piece of software you will ever adopt in the future.
> At first, it seems useful for software development, but trust me, if you get deep enough in it is way more important for system management.
I don't doubt this is true. But there is a cost of time and energy to get deep enough in it, and I was unable to convince myself that it was worth it during my time using the OS. I really wish that weren't the case, I love the idea of NixOS, I just can't justify learning it for a singular personal system, because it forces you to have a deep understanding of the Linux-y systems you're encapsulating, and the Nix-y layer on top.
I have had this feeling for some time as well. NixOS puts you on a power trip -- you can bring up and tear down systems in seconds; you can relentlessly experiment without repercussions; your repositories work reproducibly.
But I also learned that whether using NixOS is productive very much depends on what software ecosystems you are working in. When I was primarily doing Rust for work in Emacs, it worked marvelously.
When I switched to CLion (for various reasons), cracks started to show. CLion does not work well in combination with nix-shell, so when you switch often between projects, you end up with projects that don't build because you are not in the right environment. Currently, I am doing more Python development, and that is an absolute pain with Nix. You end up needing different sets of package versions (which are not packaged in nixpkgs) in different environments. If you need to change multiple packages in tandem, you want mutable state. The best you can do is to make a FHS environment with buildFHSUserEnv, which kind of works, but is not very smooth. At which point you realize that you are basically fighting the system.
Then there are the niches that are not well-covered. Over the past year or so, I have had to do GPU profiling more recently. Last time I tried, the usual NVIDIA tools (e.g. Nsight Systems) worked very badly on NixOS. Of course, it's a big proprietary blob with all kinds of FHS assumptions, but you need to get work done.
These are not all failings of Nix or NixOS, it is more that there are a lot of software ecosystems out there that are not really prepared (yet) for an non-FHS, immutable world.
but I’ll be damned if it’s not a preview of the future
I think for most Linux users, Fedora Silverblue is probably more of a preview of the future. It doesn't have all the features that NixOS provides, but it does have many that matter (immutable base system, atomic upgrades/rollbacks), while going further than NixOS in other departments (verified boot, SELinux, git-like store of blobs). It sticks to FHS, so a lot of existing software continues to work.
Edit: this comment is about NixOS on the desktop. I think the server is a completely different story.
I tried to solve many of the same problems in Arch Linux with aconfmgr. It attempts to achieve reproducibility by using a model where the state of the entire system must be represented in the configuration file, and it helps transcribe any changes back to the configuration (unlike classic configuration managers, which only manage what is declared).
First off, I have a quite special environment for work. I like to customize many aspects of my desktop, and having my environments on other machines to work similarly is a tedious task, especially when having more than two computers you use daily. NixOS solves this issue very well.
What makes it hard is how docs are not that great for Nix or NixOS. What all of us have to do is to read other people's dotfiles and the nixpkgs monorepo to understand how things work and what can you do with it. It is extremely hard in the beginning, even for people like me with over 20 years of Linux experience. It took me about six months to finally being able to get it.
There are some new terms you hear when you first start using NixOS. One is flakes, that is very vague and academic at first, but when you understand what it does it is almost as hard to go back to Nix without them as it is for seasoned NixOS user to go back to using other operating systems. With flakes, you have two files:
- `flake.nix` lists inputs, such as git repositories, of nix build instructions for fetching packages and functions to your system.
- `flake.lock` is like your normal `Cargo.lock` that sets the exact commits of all inputs, freezing the versions of all software in your system.
This means I can mix things really nicely in my system. I can use the master branch of Sway, the pgtk version of Emacs with Wayland support from the emacs version control (not even master branch) and mix and match things from different NixOS versions. I can even fork the NixOS monorepo, do some changes and add them to all of my systems before my PR gets merged.
The `flake.lock`, which I commit to my repository, forces every single computer I have to use exactly these versions of the software with the configuration I give. It will always lead to the exact same result when I `nixos-rebuild switch`. When I want to update my packages, I go to the repo and say `nix flake update`, then switch to the new versions and only if everything worked with the new packages, I commit the `flake.lock` and it works everywhere else the same.
The other nice thing I learned, is while at first the nixpkgs feels like a crazy mess and hard to grasp, it is actually one of the best package repositories I've used. Being a package maintainer is easy and a PR that follows good coding standards gets merged to the main repository no matter how experienced Nix developer you are. See my first package I started to maintain:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...
These 23 lines of nix will fetch the package with the given tag from GitHub, check the file download SHA256 sum matches the given, check the vendored libraries SHA256 sum matches the given and then will just use the system `buildGoModule` function to compile the package and put it to your system. When their CI catches changes here, it will build a binary cache for the derivation, so most users won't even need to compile anything, but get a binary derivation with exactly the same result as compiling it by themselves.
And it's easy to see what gets added to your system. You can see the repo and read the code. You can use your editor, go on top of `buildGoModule` call and jump to definition, and you can read the definition what the function does. Now some users are running bots that just go through many packages in the nix repo, change the versions and SHA sums if they have updates and automatically generate pull requests, saving the maintainers the work to do it manually.
I understand this is not for everyone. But I hope I also could make you understand why there is no way of going back to systems like Arch Linux, Ubuntu, Windows or macOS after getting some proper taste how to do things with NixOS.
Here's my config so far:
https://github.com/pimeys/nixos
I'd like to see other configs from nix users too if you're still here!
Here's mine https://github.com/warbo/nix-config
I've used Nix/NixOS for about 8 years, but not delved into flakes yet.
My solution was to fetch a Debian filesystem, chroot into it (using proot) and run 'apt-get install chromium'. The result is an immutable Debian with Chromium installed. My chromium executable is then a script which chroots into that filesystem (again using proot) and runs chromium.
It's not reproducible, but it's simpler than maintaining a list of all the required .deb files and their SHA256.
I just use Mac OS X and don't spend hours configuring my machine / talking about it... lol
Modal dialogue strikes again?
Anyways, you didn’t qualify “hours” as being relative to any other timeframe, so I’m not sure if you literally mean you’ve spent less than one hour configuring your machine and/or discussing its configuration. However, you seem to wear it as almost a badge of pride, and I even sense some condescension, and I find that pretty silly. That’s like being proud of not learning another language. If you wanted to argue my time investment was worthless, you would have to know it gained me nothing versus just using macOS. However, given that I decide what’s worth my time, this is honestly pointless. I actually enjoy trying to improve my setup, especially in ways that makes my life easier.
It’s easy to see a bunch of Linux nerds talking about text editors or WMs and conclude it’s a waste of time, but I disagree. It’s only a waste of time if you have no interest in exploring it. As for the tangible benefits, I may very well have more macOS experience than you do Linux experience, so from what standpoint are you qualified to even judge that, even that angle were truly relevant?
Even if I loved the macOS interface, I sure as shit don’t love Apple. How much would I have to pay to get performance equivalent to my 5950X on macOS? Is there even such a thing? I could use Linux/KVM to make an AMD Hackintosh setup, but I better be careful to spend under 60 minutes on configuring it lest I sacrifice my benefits.
I'm almost the same, but 3950x instead of 5950x. I used Mac OS X between versions 10.0 and 10.4, and can never go back. It gives me anxiety, even now when I have a M1 machine in the cloud from work I mainly use through SSH, the system just feels like it fights hard preventing me of doing what I want.
I sure hope so open hardware continues being a thing, and we're not forced to some proprietary way of doing things. I still have fun with computers and operating systems. I love to experiment, and finding things out is the only reason I'm in the business of programming.
OS X works fine if you're content with it's limitations. It becomes a straight-jacket if you're not.
Even choosing furniture purely based on function is a stylistic statement.
In any case it's obtuse to focus on this as the point of my statement was clear: that customizing an environment you spend much of your day in matters - that applies whether you only care about function or care about appearance too.
I have to say that overall, nowadays, the environment doesn't affect me much, most of the time is spent inside a text editor and the rest is inside a browser. The widespread use of docker removed the need for most package management (the worst thing about Windows and Mac). I use nix-darwin to manage most dependencies on Mac which is okay, albeit not a great experience (nowhere close to nixos on Linux).
I'd rather use Linux + sway when given the choice but I can, stoically, make work with pretty much anything.
Maybe for junior devs lacking the leverage to decide what they want to run, but thankfully I don't have to put up with that.
(It's of course fine to actually prefer OS X, but putting up with it if you don't is another matter)
Most of my time is also spent inside editors or browsers, but the window manager matters a lot - to the point the majority of config changes I've made on a stock Ubuntu install is my window manager config.
It’s the OS equivalent of making an unrepairable device. Linux and the piles of mutant userspace hanging off of it may well be pretty inconsistent and janky, but you can actually take a wrench to them — they are repairable.
(Solved my problem by running a win32 version of my app instead, in 32bit Wine on Debian.)
Some people are happy to lease a Hyundai for 3 years. I’m more into owning my own bikes, and doing all my own maintenance :)
I do have a laptop running NixOS, but it is just a Thinkpad T60p from a few years back. It works OK, but I can’t say I strongly recommend this. I was at least able to get Intel’s cool GPU virtualization technology working under NixOS, but the iGPU in that laptop makes me wonder why one would do that.
- ThinkPad X1 Carbon 2018 model. Even the fingerprint reader works with this one. And fractional scaling for the 4k monitor! Config: https://github.com/pimeys/nixos/blob/main/hosts/purrpurr.nix
- ThinkPad T25. Everything except the fingerprint reader works. https://github.com/pimeys/nixos/blob/main/hosts/muspus.nix
- ThinkPad X230: Everything works here. The classic workhorse. https://github.com/pimeys/nixos/blob/main/hosts/meowmeow.nix
I never tried anything else except ThinkPads just because I'd miss the TrackPoint a lot...
Nothing, it isn't like Xorg will stop working and a lot of the infrastructure between current X11 and Wayland servers is shared anyway.
The standalone Xorg server may or may not get an official update from its original maintainers but there are enough users out there that if something breaks or doesn't work and someone implements it, it'll be picked up by others.
It isn't like X11 is tied to the current most popular X server, if enough people feel like it it will be forked - Xorg itself is a fork of a fork (XFree86) of a fork (X386) after all.
A slightly longer answer is in a bullet point on our fundraising page (https://github.com/sponsors/xmonad):
> Wayland: It's becoming increasingly clear that the days of X11 are over and some Linux distros are already switching to Wayland. We're committed to keeping xmonad on X11 stable and alive as long as necessary, but if time allows, we should explore the Wayland ecosystem and figure out what it means for xmonad. Do we go all in on waymonad? Shall we try to keep xmonad a pluggable window-management component for another Wayland compositor? Honestly, we don't know yet. This one is a bit of a stretch goal: we might need more than one person full-time to actually make this happen.
Elsewhere in this thread, I wrote about some concerns I have about waymonad and xmonad on Wayland in general: https://news.ycombinator.com/item?id=28796909 The gist of it is that I'd like to keep the compositor and WM separate, because a) xmonad is reconfigured by compiling/restarting, b) I don't think the Haskell runtime is good for handling input and presenting frames, c) I don't want to maintain a compositor :-).
I am surprised, at least somewhat (and as someone with very little Haskell experience,) to hear Haskell may not be a good fit for the compositing bits. That’s a bit disappointing because the stability of Xmonad is probably a big selling point, and even more important with a Wayland compositor, but most of the Wayland compositors have quite a lot of C code. Maybe the same will wind up being true of the compositing bits of the Wayland equivalent of Xmonad.
I only use one screen, so I'm pretty sure I'll switch back to something Xorg-based sooner or later. It's not perfect but at least it always remembers to redraw windows.
Love to hear more about this, DPI is one of the big problems I continue having on xorg. 4k screen makes this hard. How is the story on backwards compatability with xorg? Do stuff like zoom screenshare work?
Just tried Sway, but unfortunate I get the black screen of death it seems :/
First, it's not that Wayland is bad, but it's simply not there yet. It still needs more time and effort. Nothing is wrong with this. What's wrong is trying to shove that thing into people's throat.
Second, NixOS is overrated for desktops. It's good for reproducing specific environment, but, unlike servers and dev envs, in desktop environments, changes are made from both software and user side frequently and sometime radically. ROI is significantly lower, and NixOS still can't save you from long-term breakage.
What I can say is that you're just riding on hypes, and never looked into the true abyss. If you're into rock solid systems, nothing can beat full-time suckless. Ditch those "modern" stuffs like systemd and smart DEs, and you get perfectly predictable system. Do that on Debian, an you have nothing to babysit at all.
I used XMonad for many years and finally had to give up and switch to i3, so I would recommend using that
The first problem was that they broke my configuration file with every release. I'm not a Haskell expert so fixing it was very time consuming
The second is that their gnome integration is quite bad. Also it's different for every combination of XMonad version and Ubuntu version and eventually I hit a combination that I couldn't get to work
So it was great when it worked but it didn't always work, and I'm now a happy i3 user
This is the same reason I gave up on AwesomeWM—sometimes things would break and it would take a long time for me to figure out how to fix them.
Nowadays I use i3 as well. Sometimes I do wish the configuration language was more powerful, but I value the stability a lot more.
From a maintainer PoV, this is often a pain since AwesomeWM exposes most of its internal guts, but with enough compatibility code and Android style API levels, we still manage compatibility pretty well.
Glad it works for you!
I just use a one line config that selects the gnome integration. Always worked great for me on Ubuntu. I think there is little reason for most to do much configuration of XMonad.
From their homepage: "Regolith is a modern desktop environment designed to let you work faster by reducing unnecessary clutter and ceremony. Built on top of Ubuntu, GNOME, and i3, Regolith stands on a well-supported and consistent foundation."
I'm not affiliated with the project, just a happy user.
One thing that I set up in `xmonad.hs` is `additionalKeys` that switch to or launch particular programs. For example:
((mod3Mask, xK_f), raiseNextMaybe (spawn "/usr/bin/firefox-esr") (className =? "Firefox-esr"))
((mod3Mask, xK_r), raiseNextMaybe (spawn "urxvt -name mtr -e mtr 123.45.67.89") (className =? "URxvt" >> title =? "mtr"))
myLayout = tiled ||| Mirror tiled ||| noBorders Full
where
tiled = Tall nmaster delta ratio
nmaster = 1
ratio = 1/2
delta = 3/100
I used to have a status bar and system tray, but got rid of them. The only thing I miss is having a clock I can glance at, so I wrote a key sequence that runs a script that uses `osd_cat` to temporarily overly the current time and date, time in other zones I'm dealing with, and battery status.
But its really hard to switch off it! I've tried i3 and really like that it has a network based API, but not having automatic layouts is really a deal breaker for me. It seems like you should be able to port the XMonad layouts to i3, but in reality their models are different enough that I doubt you could ever make the same layouts in i3 and have it work exactly as it does in XMonad.
there is layout saving on i3 now and it works pretty well.
basically you build a layout on a workspace, dump it to a file, adjust window selectors so that they swallow the correct windows, and then you can apply it a piacere.
Personally I prefer the latter.
[1]: https://github.com/olemartinorg/i3-alternating-layout [2]: https://github.com/chmln/i3-auto-layout [3]: https://github.com/nwg-piotr/autotiling
I wrote Vivarium[0] specifically to be a wayland compositor that behaves exactly like my (fairly simple) xmonad config, but it's a relatively new/unstable compositor and nothing like xmonad internally.
River[1] has a fantastic tiling model via user-provided executables, which makes it very flexible and probably a good fit for many people wanting something xmonad-like.
Waymonad[2] exists as a direct xmonad-like compositor, but I think development has been basically stalled for a long time. Sometimes there's discussion about reviving it though (edit: see https://news.ycombinator.com/item?id=28796909 for more up to date detail).
Japokwm[3] is another compositor with xmonad user roots, but again its own tiling model.
[0] https://github.com/inclement/vivarium
[1] https://github.com/ifreund/river
But here's where I always get stuck on such things with Linux in particular:
1. It's usually a whole new set of keybinds I have to learn. I feel the same way about tmux/screen, emacs and vim and the like. For the others I get that there is a point because you can use all of them in vt-environments (eg over ssh connections). Whatever the case, they all represent a cognitive load that I have difficulty motivating myself to summit. You just get a lot of behaviour for free with a traditional mouse UI;
2. An esoteric scripting/configuration language, in this case Haskell for XMonad (it seems?). Often the out-of-the-box defaults will be sparse and/or rough and you'll have a whole bunch of conflicting advice on how you should modify that.
This works for many people and I"m genuinely happy for you.
Are there any tiling WMs that are a little more... accessible?
You might like Regolith, which is basically an opinionated i3 setup you can install on top of Ubuntu as a set of packages. It integrates with Gnome and is ready-to-go out of the box, compared to manually installing and configuring i3 and its accessories.
It's also available as a LiveUSB and complete install if you prefer that route.
The bindings are pretty simple like screen/tmux.
It's quite bare and simple.
An advantage for low vision of tiling WMs like ratpoison is that you can keep all applications full screen and flip between them very fast.
But flipping between full screen apps is probably where I need to be so I'll check it out. I appreciate the suggestion.
Yes! Pop shell by system76. It's an extension to gnome and not its own window manager so you get stuff like volume keys, screen brightness indicators, status bars display settings, and so on for free instead of needing to piece together a separate solution for every tiny thing.
You can do everything with a mouse if you want. I've started with just using a mouse and every few weeks I try and learn a shortcut or two for what I do most frequently.
dwm is a tiling window manager with very similar keybindings to XMonad, and it's written in C. I used it for a bit before I switched to XMonad... I mostly discovered that if you were fine with the default configuration, they were largely interchangeable, but XMonad had a more sizable community and much more options for configuration. The config is also not that bad to copy/paste and treat as just a bizarre config file syntax (of which I think we've all used many).
Personally I think a tiling window manager works at least as well with 1-2 windows on the screen as with tons. I actually don't use one now (I'm mostly on Windows for work) but I extensively used it on my netbook which didn't have the screen space to effectively use more than two windows.
Similarly, I've memorized new window and new horizontal/vertical split for tmux and that's like...98% of my usage so I'm set. vim definitely requires more effort, but the payoff for me was making it so that I'm always either in the terminal or in firefox. I still use the arrow keys to move around in documents and I've been using it as my daily driver for work for years.
As a result, I have two monitors, one dedicated to firefox and one to the terminal (includes vim + db clients + everything else). I don't split my terminal like crazy, almost very tmux window is fullsize. I split vim 3-4 times at most and make use of a buffer-switching list thing that's way more intuitive to me than remembering the vim commands to cycle through them.
Most of the reason I use a wm is because for two applications, I don't need window decorations and it just seemed like a waste in general.
For the amount of power-user tools I use I feel like a totel poser. But it works for me, and I think that's what matters.
I recommend a TWM if you have the time and the energy for that, if you want to tinker a lot your environment. It can be pretty cool, but also a drag. There's always some little thing to fix, and basic things are simply not part of the package. So be prepared to write scripts and use third party tools with varying degrees of documentation for many things you take for granted on a desktop environment.
Regarding your other concerns, you can literally change all keybindings on i3wm, so you can make them follow the logic you're already used to. And i3wm is great for working fullscreen as well.
I browse HN with 240% Zoom on 23" 1920x1080; vscode: font "Iosevka SS16", font size 33px.
So because of that I use i3 WM (...I have never used other tiling WMs):
On every virtual desktop I press Win+w (or sometimes Win+e if the monitor is rotated) to enable "Tabbed container layout"
and then I can switch between windows immediately by Win+Left and Win+Right.
With Win+w all windows use 100% of the display width and 99-100% of the display height (I also set border width 0px and disabled taskbar/statusbar), i.e. they are maximized.
Windows have no their own title bar, but you can see the window titles on the very top of the screen.
Since a window can use more space, I can use bigger fonts without being shown almost nothing.
Well, KDE probably too has an option to launch windows maximized by default, but probably not the other features.
> 1. It's usually a whole new set of keybinds I have to learn.
I use the i3's defaults:
1) Win+1..9
2) Win(+Shift)+Up/Down/Left/Right
3) Win+D (similar to Gnome's ALT+F2)
4) rarely Win+Shift+Space (disables tiling for a window)
5) rarely Win+Space (enables tiling back for a window)
That's all (also Win+Shift+j to reload the i3 config but I didn't remember this hotkey for years).
But if I had a 46" 4K monitor, I would use i3 as most others do (i.e. multiple windows are shown at the same time).
For the amount of convenience, this is a very small price to pay.
Eventually, I found my way with qtile [0], written and configured in python (which I do speak sort of). It is extensible, simple and just works. I use it daily for nearly a decade now. What I like, qtile has modules to manage the window layouts. My favorite is the xmonad-clone which mimcs basic features. But efficient enough for me 0: http://www.qtile.org/
Another tilingwm I like to mention is spectrwm [1] which I use as a backup. I cannot say that qtile never had issues. But it is also a long time ago I used my backup. qitle is now in my OS repo, so I don't need to build and install my self anymore. 1: https://github.com/conformal/spectrwm
That said, many thanks to xmonad for opening a path and inspiring other projects
OT: I've falling back in love with Haskell after reading Ben Lynn's astonishing adventures (https://crypto.stanford.edu/~blynn/compiler/) and it's still super awesome for explorative programming.
But they refuse unicode, and I refuse dwm.
i3 is workable, and that's what I am using.
Once I got over the hump with Nix, I found it easier to manage and improve my Linux configuration than on "traditional" distros I've tried (Fedora, Ubuntu... etc).
Unfortunately, the learning curve was pretty brutal, and I don't think I would have made it over without using Nix for development (without NixOS) first on both my projects and at work.
NixOS is neat.
And "OS setup from git repo" is something NixOS is excellent at.
However, the effort it would take for you to come up with your own NixOS configuration would be much greater than what it would take for you to just re-configure your system each time & keep notes (or write the commands down as scripts).
I think the dissuading points under "Should I use NixOS?" are pretty good. https://github.com/hlissner/dotfiles#frequently-asked-questi...
I just cannot imagine I would spend less than 4 hours figuring out NixOS and its DSL. Even if I setup a fresh OS twice a year I just don’t see it being worth my effort — beyond learning a cool new OS.
Arch works well for me and I like the package ecosystem / rolling releases.
My killer feature. It makes having multiple monitors so much more productive. I don't want one larger screen with a big dead spot in the middle. If I want a large/wide screen I will just go out and buy one. I want more places to put stuff.
But I prefer tiling most of the time on a large screen too, mostly because makes manipulating windows with a keyboard faster to have a simple, predictable layout. In practice I usually end up with 2-4 windows per workspace, with a few with 1.
To add to the rest of the discussion. I've tried different tiling wms. Starting with qtile (written in python) to awesome, xmonad i3 and now I'm on sway. I think xmonad has the best way of dealing with multiple screens (tags are essentially independent of screen), which I missed originally when moving away from it. Fortunately there are some python scripts to emulate the same behavior on i3/sway.
The way I've done this has changed a bit over the years, these days I drop a file in .config/autostart letting xmonad replace the normal window manager after Gnome gets itself sorted out.
I like to be able to have one application on top of another and especially not using the WHOLE partition. Don't create artificial constrictions for yourself. Some applications are designed to work only with a specified width and height.
I guess it's fine if you use your computer just for the command line stuff.
My guess is that most other tiling wms would have a straightforward way to float windows as well.
In my configuration, I also have it set up that if I hold the mod key and drag a window with the left mouse button, it becomes floating. Mod+drag with the right mouse button resizes it, pretty similar to the i3 setup you mention.
I understand the whole issue with nvidia and their asinine drivers, so no need to come down on me. Hopefully things change in the future with Nvidia cards, I absolutely love the experience Sway provides on integrated intel gpus.
For passthrough, just have another graphics card and follow the Arch wiki for installation. It works quite well: