Moving Back to a Tiling Wm – Xmonad
Postedabout 2 months agoActiveabout 1 month ago
wssite.vercel.appTechstory
calmmixed
Debate
60/100
Tiling Window ManagersLinux Desktop EnvironmentsWindow Manager Configuration
Key topics
Tiling Window Managers
Linux Desktop Environments
Window Manager Configuration
The author shares their experience of moving back to XMonad, a tiling window manager, sparking a discussion on the pros and cons of tiling WMs, their configurations, and comparisons with other WMs and DEs.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
31m
Peak period
73
Day 1
Avg / period
37
Comment distribution74 data points
Loading chart...
Based on 74 loaded comments
Key moments
- 01Story posted
Nov 14, 2025 at 12:04 PM EST
about 2 months ago
Step 01 - 02First comment
Nov 14, 2025 at 12:36 PM EST
31m after posting
Step 02 - 03Peak activity
73 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 24, 2025 at 5:17 PM EST
about 1 month ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45928873Type: storyLast synced: 11/20/2025, 5:02:38 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
I bind Alt+Shift+H to run "windowfocus left", which figures out which window is "to the left" based on some heuristics such as the direction between the center of the active window and the other windows on the screen. Since it works uses the center of the window, it works with overlapping windows (but intentionally excludes windows that are occluded).
I've used it in both xfce and kde (though not recently).
Essentially turning kwin into a tiling WM
Conceptually, it's like an infinite 2D canvas windows, divided into strips (strip is a workspace), and you then scroll through an infinite ribbon of windows in each strip.
Seems interesting, but also slower and less flexible than traditional tiling WMs (least of all because of the slow scrolling animations, but also because it seems to prefer scrolling instead of jumping-towards).
Like most of the 'tiling with gaps' patches I see, these feel like trying to look fancy without necessarily delivering big value. I'd be interested to hear why people want a scrolling WM. Is it merely more visually pleasing?
This is opposed to a traditional tiling WM where you'd either need to open the app in another workspace, use some stacking feature or worst of all shove the new window into the current view by resizing some other window(s) which is often not ideal.
I never want to / have to wonder where any particular window is. Every app will always open on the same workspace, in the same position that I define + a scratchpad workspace for random one-offs that I keep floating. I'm only ever 1 key press away from exactly what I want. I know that ctrl+b gets me my browser, ctrl+t gets me to my terminal(s), etc. I don't even think about the workspace numbers or layout beyond initial configuration. Zero animations, instant switching.
In your example, if I'm on one workspace working and I need to open Gimp, I press my keybind for Gimp and it opens on the scratchpad and switches to it immediately.
It takes a lot of initial config and tweaking as you go along but once settled it's the most efficient way I've found to manage windows, in that, the windows manage themselves i no longer have to think about them at all.
In Niri, you just have these open in the each workspace off to the side. And you know exactly where each one is.
In your example, you either have to flip through multiple Gimp instances in your scratchpad or you use tab/stack containers to tile them in to existing workspaces. But you are multiple keystrokes away now because you have to go to the container and paginate through it.
I'm often working on 3+ codebases or projects at the same time, each project has a browser window with associated tabs, an instance of an editor, several terminals. So they get a workspace. "Switch to browser workspace" makes no sense if there are 3 instances of the browser open, especially when I want the browser next to my editor for live reload/API docs.
I use Awesome Window Manager and one feature I like about it is this:
Say I've got my terminal in workspace 1, Firefox in workspace 2, and Emacs in workspace 3. There are often times I need to use either the terminal or Emacs (or both) while viewing a website. So with a keystroke, I can tell it to combine any two or three workspaces and all the windows are shown tiled together. In a sense, it creates a new temporary workspace with all 3 windows. As soon as I leave this workspace, it restores it to the original configuration. No need to move windows from one workspace to another and remember to move them back.
This is the one feature that I'm really missing from Mac OS.
If you press Mod4 + Control + 3 again, it will remove workspace 3 from view.
If you now just leave to go to some workspace, (e.g. Mod4 + 5), it will only show workspace 5.
Can't live without it.
You can get similar functionality with tabbed windows, but I'm still trying to decide which workflow I prefer; scrolling feels a bit more "organic", while tabs are superior for density.
Switched workspaces I know what is on each workspace, I can switch to it, see what's there. But the Niri approach, I have to scroll through the space to see which windows are actually there.
Overflowing Gimp onto another workspace because of this is the main cause of workspace spam that a scrolling WM solves.
If you're working on more than one project (so, workspace 1 2 and 3 are fully utilized), where does this overflow workspace even live? And what if each workspace also needs its own Gimp instance?
There are certainly solutions to this in every WM, but the scrolling WM solution is a really simple one that never makes you ask the question of where to put something: workspaces have an offscreen overflow area.
Another way of thinking about it is: sway would be instantly improved for me if it also had a per-workspace overflow area, like maybe if every workspace had its own scratchpad that I could tile windows on, and I could reach it by moving focus into it kind like moving between monitors.
Workspace 1: Browser, Email, Music
Workspace 2: Running project, editor(s)
On sway/i3 I always had these things split across multiple workspaces it could get tedious switching between them at times.
Type-checking keybindings is cute, but you're going to discover that the keybinding doesn't work when you go to use it, so how much time are you really saving? That's not helped by the fact that many WMs/compositors have validators for their configs, so you're getting much of the same benefit with much less trouble.
For reference, Niri's config is very approachable: https://github.com/YaLTeR/niri/blob/main/resources/default-c...
Not for me. I don't know Haskell, and I had to cargo-cult forms to do what I want (which bothers me, as someone towards the end of the developer spectrum that likes to understand well how systems work).
But XMonad with a few cargo-culted tweaks works noticeably better for me than I've been able to configure i3wm. I forced myself to use i3wm at one company, for two years, rather than bring over my Xmonad config, and every evening it was a relief to be back using Xmonad on my personal laptop.
So if your side screen has say documentation open, and you switch on your main screen from terminal to editor, only the main screen changes. The side screen stays untouched. Some people prefer it, some hate it. But it's good that xmonad offers it. It also has hot reloading of the config, which is also nice.
Sure, Niri's config is approachable, but is it hackable? It only offers what Niri offers, right? You can't extend its functionality by config alone.
That is where XMonad and others shine. Sure, they might not be for the "I don't wanna spend time configuring my WM to death" crowd (and I mean absolutely no derision in that. We all have different rabbit holes we want to customize to oblivion), but Xmonad or Stumpwm etc allow for those shenanigans, and I myself am very very happy to have those.
Long story short, it's not all 100% about the type safety, it's also a lot about the extensibility of it.
Niri is nice, not mocking it. But infinite scrolling is not everyone's jam. Some others might even question the choice of KDL instead of JSON without any clear benifit.
Whatever you prefer and if it works for you, great. That's why we have choices ^^
> Especially how it handles workspaces on multiple monitors. By default, each monitor has one workspace. Not one workspace for ALL monitors.
I'm pretty sure this is the case for most tiling WMs; it's definitely the case for Niri (https://github.com/YaLTeR/niri/wiki/Workspaces), and I'm pretty sure it's the case for sway.
> It also has hot reloading of the config, which is also nice.
Niri will reload your config on save; Sway requires a keybind, but no restart.
> Sure, Niri's config is approachable, but is it hackable? It only offers what Niri offers, right? You can't extend its functionality by config alone.
Most Wayland compositors offer that extensibility through messaging; you would send messages to Niri or Sway through scripts to achieve custom behaviour. I do miss having scripting built-in in AwesomeWM, but it hasn't been too much of an issue for me in practice.
> Niri is nice, not mocking it. But infinite scrolling is not everyone's jam. Some others might even question the choice of KDL instead of JSON without any clear benifit.
I brought Niri up as an example, but the general point I was trying to make is that the other tiling compositors/WMs out there offer similar solutions that get you to the same place, but through easier means. As for KDL, I think it would be difficult to argue that JSON is easier for humans to edit than KDL :p
> Whatever you prefer and if it works for you, great. That's why we have choices ^^
By all means! I'm not denigrating XMonad or such here; it's more that I think it's probably not the right choice for most people in the market, as there are alternative solutions that are likely to get you to the same place with less friction.
And sure, you can send message and commands to Niri via IPC, but that is very very different from say XMonad or StumpWM where you can actually override or alter functionality within the config instead of having to change the original source code.
That I'd say is the very definition of hackable. When you can actually just throw stuff into your config to change core behavior.
No, it doesn't seem that way. The Niri manual says each monitor has an independent set of workspaces. In XMonad there is one shared set for all monitors, but each monitor independently shows one of those workspaces.
(If the user tries to show on monitor A the workspace currently visible on monitor B the two monitors swap their workspaces.)
This is the reaon I use XMonad, and I hate how this one design choice that only one window manager has gotten right is what locks me into X11. If anyone ever learns of a non-X11 window manager that handles workspaces on multiple monitors the XMonad way, contact me!
See https://github.com/Kintaro/wtftw It handles screens the exact same way Xmonad does, because it was modeled after Xmonad. The config is entirely done in Rust, so it allows for a lot of hackability. On reload, the config gets compiled to a dynamic library and the WM restarts itself, passing the current window IDs to itself to "reload".
But I was meaning to pick up a new project in 2026 for myself. So maybe a CL based Wayland WM with an Xmonad style?
It's not about discovering it doesn't work so much as discovering the specific reason it doesn't work.
This meant that instead of e.g. spawning some utility on a media key input, the compositor could directly stay connected to the dbus and control mpdris clients directly.
The way I see xmonad in retrospective today is that it is/was a "make your own compositor" library much like wlroots, smithay, etc, but it came with enough of the batteries included in the package that spinning up a nice and productive environment took barely any code. Something you can't really do with wlroots or similar.
I've been on HyprLand for a week now and haven't hit any blockers yet that'd force me to go back to KDE.
I'm mostly pointing out that the documentation is very easy to read and implement for most tiling WMs, without the need for a coding agent.
But I'm primarily talking about the missing pieces that most tiling window managers have that you need to implement yourself, or the annoying bugs that are buried in github.
I need a lock screen; fine, hyperidle. How is it configured? Once it works it works.15 seconds with Claude or 2-3 minutes googling and implementing. Why the hell would you not use it?
QT apps have fuzzy fonts in Hyprland. Turns out that's because I was using 1.5 fractional scaling on my 4k monitor, which was information buried in some github that has barely any traffic, which Claude found while I was doing actual work.
The google meet PIP window strobes because who the hell knows why, but that too was solved by Claude finding the right github ticket and applying opacity 0.999 instead of 1.0 for that window specifically. Where is that documented in the hyprland manual?
The point is that tiling window managers _in my experience_ always have rough edges, and I've been dipping in and out of them for 20 years. Now that many people (I guess not including your good self) are using LLMs all day every day to move faster in producing code, you can apply the same tooling to bring the tiling environment up to the same level of quality that we're used to with the bigger DMs that have a lot more resources and eyes on them.
It's the lua scripting that really pushes it to the next level for me. I think I fell in love when I set up randomized times wallpaper rotations, and then realized that I could also create multiple profiles/sets of wallpapers as well, and the only limit was my own ability to add it.
Spectrwm is not well known, but it fits this sweet spot between super simple with few moving parts yet still configurable enough to work the way I want to. far simpler than xmonad or even I3 but with better defaults and more easily configurable than dwm.
It is like when you buy an appliance and it just fades into the background and then, one day, you realize you've had it for 10 years without any problems and you feel a tinge of gratitude before moving on with your day.
Is the author saying that until 2019 they used Linux on the desktop without using X?
Obligatory dotfiles: https://github.com/aclough/dotfiles
But right now I feel like I should be thinking of moving over to some new Wayland system. Maybe Niri and XFCE?
It's very fun to rice a setup and make something worthy of posting on r/linuxporn.
In the old 4:3 days I used ratpoison for a while, but after months I went back to fvwm. On 4:3 it seemed to work great, but I tend to think on these 16:9/16:10 monitors it could be a PITA. I believe I would need to move my head to the right a lot. On 4:3 no such issue.
FWIW, via fvwm I force all my main applications to place themselves on the left 2/3 portion of the monitor. The right 2/3 are for things like xmag, clocks, monitors and FvwmButtons/FvwmIconMan.
I started with i3 and really like the keybindings. A couple months later I found out about xmonad through general interest in the subject. I installed it, found someone's config to use i3 keybinds (which I was used to at that point) and had a lot of fun. It's definitely quick as heck and I like how compact the codebase is for edits. Plus, it gave me an excuse to learn some rudimentary Haskell.
My visual setup is always SUPER minimal, as it comes out of the box. So that was nice.
Unfortunately I had some serious trouble with X11 and an app my workflow relies on running in wine, so I switched to sway for Wayland (such as it is it fixed the issue). I know some folks from the xmonad community are trying to implement it over Wayland [0], and were it to come to fruition it would be a VERY welcome development.
[0] https://discourse.haskell.org/t/xmonad-for-wayland-call-for-...
My absolute favorite feature (i'm sure this is present elsewhere too) is the idea that I have my stuff laid out on virtual screens and I can just assign a virtual screen to a physical screen super trivially without ever moving my hands off the keyboard. It's such a wonderful workflow.
Tiling WMs are one of those power user things where once you get used to it the other way just seem so obviously bad. VIM and Blender are similar, unfamiliar annoying interface if you're used to the normie way of doing things, but once you understand the patterns and the way you can compose them it becomes so much more expressive.
3 more comments available on Hacker News