Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving Back to a Tiling WM – XMonad

wssite.vercel.app

Post reply on HN
Print view View original

71–80 of 84 posts

Re: Moving Back to a Tiling WM – XMonad

#71

Post by nicklaf »

errantmind wrote: post #63

The best part about choosing a simple WM is you never have to think about it again. I installed and configured DWM many years ago and it just works. Never had a single issue after the first week. 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.

Same story here. After installing dwm years ago, I've more or less stopped thinking about window managers as an open problem to be solved. I suppose one could run into trouble if they started patching it a lot, but in my experience you don't need to do that.

Re: Moving Back to a Tiling WM – XMonad

#72

Post by somat »

zem wrote: post #59
somat wrote: post #58

Earlier quoted context omitted.

If we are doing a survey I use spectrwm and it has empty/dedicated workspaces. It also has a concept of shared workspaces, windows there are present in all workspaces, used for fleshing out common desktop ui docks and the like. I have to admit that while I spent a couple of hours figuring it out one day, It turns out I prefer a really thin/bare desktop so don't use it. Spectrwm is not well known, but it fits this swe…

does it integrate well with any desktop environment? that was the other killer feature of xmonad for me, it worked well with MATE and kde until the wayland switch. I ultimately switched to cosmic because of issues with the (wayland + DE + xmonad) stack, but I do miss the better tiling features of xmonad.

Unfortunately I don't really know, I mean as far as I can tell gnome or kde programs run fine, but I am not running any of background tooling that normally goes with a full desktop environment.

Re: Moving Back to a Tiling WM – XMonad

#73

Post by [deleted] »

Philpax wrote: post #12

Configuring your WM in Haskell seems fun, but I suspect "fun" is the primary motivator, not any kind of practical reason. 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…

[deleted]

Re: Moving Back to a Tiling WM – XMonad

#74

Post by hombre_fatal »

thewebguyd wrote: post #28
WD-42 wrote: post #15

Earlier quoted context omitted.

It's the same thing as a tiling WM, with all the benefits. You can still tile windows vertically or horizontally. The big improvement is that if I have a view with my browser, editor, a terminal or two all tiled nicely but then all of a sudden I need to open the Gimp or a PDF for some one-off work related to what I'm working on, it just opens to the right. I can move over to it and do what I need to do without messin…

Sounds interesting, but I still think I prefer using workspaces, simply because I can set window rules for predictability. 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…

The problem with your example is that you might have Gimp, a browser with its own set of tabs, and other multi-instances of apps needed in multiple workspaces as you work on multiple projects.

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.

Re: Moving Back to a Tiling WM – XMonad

#75

Post by rootnod3 »

Philpax wrote: post #43
rootnod3 wrote: post #34

Earlier quoted context omitted.

Apart from the Haskell fun, xmonad is really really good. Especially how it handles workspaces on multiple monitors. By default, each monitor has one workspace. Not one workspace for ALL monitors. 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 goo…

I'm not a Niri stan by any means - I only switched to it the other week, and was using sway/i3 before then - but I suspect that most alternatives have answers to these, too. > 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.…

Trust me, the majority of tiling WMs has on workspace for ALL monitors combined. The percentage of WMs treating every monitor as a separate unit is smaller.

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.

Re: Moving Back to a Tiling WM – XMonad

#76

Post by rootnod3 »

kqr wrote: post #66
rootnod3 wrote: post #34

Earlier quoted context omitted.

Apart from the Haskell fun, xmonad is really really good. Especially how it handles workspaces on multiple monitors. By default, each monitor has one workspace. Not one workspace for ALL monitors. 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 goo…

> xmonad is really really good. Especially how it handles workspaces on multiple monitors 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!

I got good and bad news: my own WM did it Xmonad style, but I have not updated it in years. If there is enough request I might revive it (also X11 though, so not fitting the bill).

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?

Re: Moving Back to a Tiling WM – XMonad

#77

Post by rootnod3 »

WD-42 wrote: post #39
rootnod3 wrote: post #35

Earlier quoted context omitted.

I honestly do not understand the scrolling WMs. The last thing I want to do is move my hand to my mouse to scroll. I tried them, didn't work for me. So yes, there's still a crowd of people hanging on to old tiling WMs and therefore sticking to Xorg instead of Wayland. Because you can pry EXWM and StumpWM out of my cold dead hands.

What makes you think you need a mouse?

If I an switch left and right via keyboard, why just not switch workspaces? I honestly don't see the point in the scrolling layout.

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.

Re: Moving Back to a Tiling WM – XMonad

#78

Post by jxdxbx »

As I expected lots of discussion of scrolling managers in this thread. I'll just say that I think that scrolling windows managers like Niri, which I use, are very well suited for laptops in particular. Tiling WMs always feel cramped on a smaller screen. Plus the touchpad to swipe as navigation fits really well with the paradigm.

Re: Moving Back to a Tiling WM – XMonad

#79

Post by hombre_fatal »

rootnod3 wrote: post #77
WD-42 wrote: post #39

Earlier quoted context omitted.

What makes you think you need a mouse?

If I an switch left and right via keyboard, why just not switch workspaces? I honestly don't see the point in the scrolling layout. 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.

The question is what are you going to do if you want to launch an app relevant to the current workspace (let's say Gimp), but it's not important enough to be visible with the other windows in that workspace (editor, terminal, browser) or it doesn't fit.

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.

Re: Moving Back to a Tiling WM – XMonad

#80

Post by rootnod3 »

hombre_fatal wrote: post #79
rootnod3 wrote: post #77

Earlier quoted context omitted.

If I an switch left and right via keyboard, why just not switch workspaces? I honestly don't see the point in the scrolling layout. 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.

The question is what are you going to do if you want to launch an app relevant to the current workspace (let's say Gimp), but it's not important enough to be visible with the other windows in that workspace (editor, terminal, browser) or it doesn't fit. 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…

I open Gimp on a scratch workspace and immediately have my WM jump to it. How is that different from having to scroll to it?

If I need a Gimp in every workspace I just open a Gimp in every workspace where I need one. Or even customize my Xmonad to show specific Gimp instances on select workspaces.

Again, how does the scrolling layout do me ANY favors here?

Sure, Niri takes away the question of where to place it, but it definitely doesn't help with "Where the fuck is that one window I opened and how do I find it?" I'd rather just quickly select all my workspaces in the worst case than selecting every workspace and THEN scrolling through all the windows.

If you really need THAT much overspill on a workspace I would personally rather stop and re-evaluate the workflow instead of just spilling tons of windows all over the workspace.

It feels like if you'd sit down and re-evaluate the workflow and the setup, those problems could be solved almost without a WM.

Post reply on HN