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 much less trouble.
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 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 ^^
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.
> 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.
To pile on, if I wanted an actual language to do config work I would prefer bash for simple scripting. I started using riverwm and I love its take on config. Use whatever language you want because configuring it is just running a sequence of riverctl commands. I found it very ergonomic since i can test config in the cli, I can just use a bash script to run commands — and some extra daemons like mako, waybar, and wlsunset
Back when I had my own Xmonad config – during student years with too much time than I knew what to do with – the biggest benefit to Xmonad being a haskell program that I myself wrote was that it was a program that I myself wrote.
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.
> Configuring your WM in Haskell seems fun, but I suspect "fun" is the primary motivator, not any kind of practical reason.
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.
I haven't used it in some years, but I found AwesomeWM to work well for me for the usecase of configurable predefined window layouts. Is there anything in particular about Xmonad that keeps you coming back?
I have been a happy user of AwesomeWM for years. I don't actually use the tiling layout all that much (I definitely do use it occasionally and find it useful, but usually I'm in floating or "monocle" mode). But in additional to tiling support, it is minimalist, keyboard-driven and infinitely configurable through Lua scripts which I really like. I think a lot of other tiling WMs are probably popular for similar reasons.
I've been an awesomewm user for quite some time as well and have no plans to change.
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.
I've been using XMonad since 2012, not really for any reason other than someone at HMC told me to and I just stuck with it ever since. Sometimes I wonder if there's a reason to try something else, but I already know all the keybinds and it just does everything I want.
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.
Just moved to Niri, it's incredible how snappy it is. The animation makes what you did with the window much clearer vs. other wms where it just teleports, the scrolling just compounds to that effect. The scrolling is great because it tends to work at getting things out of the way when they're not relevant and bringing them back when they are, while not ending up with tiny windows like dwm/AwesomeWM/Sway (what I've been using for the last ~15 years).
Totally agree. I had been using Sway for a few years and tried Niri on a whim. Expected to quickly dismiss it, but ended up being a convert. It's just easier to configure your windows in a useful way, and often the "right thing" just happens by default.
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.
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?
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 messing up the current layout and then close it when I'm done.
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.
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 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.
That makes sense if you use application per workspace, which never made much sense to me.
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.
Wow. My work flow with a stacking WM is that I get my tiled windows how I like them, but then if I need a new window for some reason, I just open it and it plops on top of my tiled windows without interacting with them at all. Seems more productive to me.
> 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 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.
It's a bit arcane written that way, but each workspace is a tag. Pressing Mod4 + Control + 2 means to show workspace 2. The effect is cumulative. If you now press Mod4 + Control + 3, it will be showing both workspace 2 and 3 simultaneously (and tiling the combined set of windows).
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.
I'm still a Niri newbie, but I'm enjoying the scrolling as a ways to have "subworkspaces": when I'm working on a full-stack project, for example, I can scroll between the backend and the frontend, while arranging my windows in such a way that anything useful (e.g. the browser) remains resident on screen.
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.
Checking the video and impressed how people remember all the programs they've running on the canvas and their location. In i3 have been using i3-renameworkspaces to know what is opened in other workspaces because kept forgetting.
I also find KDE to be good enough for my personal taste. I have tried different WMs, but always found the huge configuration effort to not be worth the marginal productivity gains I get over KDE + some custom keybinds
Even xfce will tile windows to 4 quadrants, left/right-halves, top/bottom-halves. I have not studied other tiling window managers enough to know what I'm missing.
gotta admit that since windows 7 added win+arrow to quickly split, maximize, i don't have a hard need on tiling WM anymore. I very rarely use other layouts like stacks ..
It's not even the tiling so much, but the ability to move directionally between windows using super+hjkl or whatever, that's the killer for me. The big DEs like KDE and GNOME can technically tile but you're still stuck with alt-tab to switch windows which is horrible.
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).
my favourite xmonad feature (that distinguished it from the other tiling WMs I've used) is the ability to have empty workspaces. that way I can maintain a persistent mapping of applications to workspaces, with muscle memory for the keybindings to switch to various apps. (also a nice trick I picked up from someone else's config file was to have a "scratch space" desktop with a key binding that either moved to it or moved back to the desktop I came from)
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 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.
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.
I use remote desktops a lot (e.g. X2go). A lot of issues seem to come up with using Super key combos on the remote desktop. Anyone know of a good solution for that?
The reason I switched to XMonad over a decade ago was actually so that I could have a tiling window manager but still have all the normal desktop environment conveniences.
I still do not understand why people like Tiling WM, maybe I should give it another try.
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 think Claude Code makes TilingWMs doable. I've always given up in the past because there have been reams of configs necessary to get to a fairly usable state, and I don't love reading manuals for desktop environments - but now it's all pretty easy to crank out.
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 believe it saves time, the documentation is available and easily digestible, and there's thousands of existing dotfiles to take from. I'd be disappointed to hear Claude couldn't do this.
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.
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 much less trouble.
For reference, Niri's config is very approachable: https://github.com/YaLTeR/niri/blob/main/resources/default-c...
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 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 ^^
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.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.
To pile on, if I wanted an actual language to do config work I would prefer bash for simple scripting. I started using riverwm and I love its take on config. Use whatever language you want because configuring it is just running a sequence of riverctl commands. I found it very ergonomic since i can test config in the cli, I can just use a bash script to run commands — and some extra daemons like mako, waybar, and wlsunset
Back when I had my own Xmonad config – during student years with too much time than I knew what to do with – the biggest benefit to Xmonad being a haskell program that I myself wrote was that it was a program that I myself wrote.
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.
> 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?
It's not about discovering it doesn't work so much as discovering the specific reason it doesn't work.
> Configuring your WM in Haskell seems fun, but I suspect "fun" is the primary motivator, not any kind of practical reason.
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.
I haven't used it in some years, but I found AwesomeWM to work well for me for the usecase of configurable predefined window layouts. Is there anything in particular about Xmonad that keeps you coming back?
I have been a happy user of AwesomeWM for years. I don't actually use the tiling layout all that much (I definitely do use it occasionally and find it useful, but usually I'm in floating or "monocle" mode). But in additional to tiling support, it is minimalist, keyboard-driven and infinitely configurable through Lua scripts which I really like. I think a lot of other tiling WMs are probably popular for similar reasons.
I've been an awesomewm user for quite some time as well and have no plans to change.
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.
I love awesome as well but afaik it’s not compatible with Wayland and never will be.
I've been using XMonad since 2012, not really for any reason other than someone at HMC told me to and I just stuck with it ever since. Sometimes I wonder if there's a reason to try something else, but I already know all the keybinds and it just does everything I want.
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.
Tiling WMs are dead. Long live tiling WMs. Scrolling WMs like Niri/Paperwm are where it’s at now.
Just moved to Niri, it's incredible how snappy it is. The animation makes what you did with the window much clearer vs. other wms where it just teleports, the scrolling just compounds to that effect. The scrolling is great because it tends to work at getting things out of the way when they're not relevant and bringing them back when they are, while not ending up with tiny windows like dwm/AwesomeWM/Sway (what I've been using for the last ~15 years).
Totally agree. I had been using Sway for a few years and tried Niri on a whim. Expected to quickly dismiss it, but ended up being a convert. It's just easier to configure your windows in a useful way, and often the "right thing" just happens by default.
Niri has been really nice over the last week since I moved to it. It has allowed me to get down to ~2 persistent workspaces instead of the usual 5-6.
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.
Niri is brilliant. It just feels so natural. All of the default keybindings and behaviors work exactly as my brain assumes it would.
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?
Looking at a video demo of Niri for an example: https://github.com/YaLTeR/niri
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?
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 messing up the current layout and then close it when I'm done.
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.
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 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.
That makes sense if you use application per workspace, which never made much sense to me.
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.
You can also set window rules in Niri :-)
Wow. My work flow with a stacking WM is that I get my tiled windows how I like them, but then if I need a new window for some reason, I just open it and it plops on top of my tiled windows without interacting with them at all. Seems more productive to me.
> 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 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.
I know how to send a window to another workspace but not how to combine two entire workspaces. Is that a default keystroke or something you set up?
https://awesomewm.org/doc/manpages/awesome.1.html
It's a bit arcane written that way, but each workspace is a tag. Pressing Mod4 + Control + 2 means to show workspace 2. The effect is cumulative. If you now press Mod4 + Control + 3, it will be showing both workspace 2 and 3 simultaneously (and tiling the combined set of windows).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.
I'm still a Niri newbie, but I'm enjoying the scrolling as a ways to have "subworkspaces": when I'm working on a full-stack project, for example, I can scroll between the backend and the frontend, while arranging my windows in such a way that anything useful (e.g. the browser) remains resident on screen.
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.
Checking the video and impressed how people remember all the programs they've running on the canvas and their location. In i3 have been using i3-renameworkspaces to know what is opened in other workspaces because kept forgetting.
Niri has an overview view to help with this. You can see all of your workspaces and their strips, and move applications from strip to strip.
Recent versions of KDE have pretty good tiling support, so it's possible to have a rich DE and good tiling.
I also find KDE to be good enough for my personal taste. I have tried different WMs, but always found the huge configuration effort to not be worth the marginal productivity gains I get over KDE + some custom keybinds
Even xfce will tile windows to 4 quadrants, left/right-halves, top/bottom-halves. I have not studied other tiling window managers enough to know what I'm missing.
Even Windows will do that, and so did older KDE. KDE 6.1+ will do a lot more than that, everything that I previously used a tiling manager to do.
gotta admit that since windows 7 added win+arrow to quickly split, maximize, i don't have a hard need on tiling WM anymore. I very rarely use other layouts like stacks ..
P.S. Meta-T to get started with tiling on KDE.
when you say tiling support, do you mean automatic tiling, or sending it to a corner via key combo?
If you want automatic tiling, there are Kwin scripts for that eg https://github.com/anametologin/krohnkite/
Essentially turning kwin into a tiling WM
It's not even the tiling so much, but the ability to move directionally between windows using super+hjkl or whatever, that's the killer for me. The big DEs like KDE and GNOME can technically tile but you're still stuck with alt-tab to switch windows which is horrible.
That's why I wrote this: https://github.com/cout/windowfocus
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).
KDE's meta alt arrow doesn't exclude occluded windows, but if you're tiling you probably don't have those
Alt+Tab is great... I wouldn't use a desktop without proper Alt+Tab (exactly like in KDE).
meta-alt-up/left/down-right by default on KDE.
my favourite xmonad feature (that distinguished it from the other tiling WMs I've used) is the ability to have empty workspaces. that way I can maintain a persistent mapping of applications to workspaces, with muscle memory for the keybindings to switch to various apps. (also a nice trick I picked up from someone else's config file was to have a "scratch space" desktop with a key binding that either moved to it or moved back to the desktop I came from)
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 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.
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.
I use remote desktops a lot (e.g. X2go). A lot of issues seem to come up with using Super key combos on the remote desktop. Anyone know of a good solution for that?
I used Xmonad for a while, then switched to awesomewm used it for years. It was good on a 1366x768 screen to use space efficiently.
The reason I switched to XMonad over a decade ago was actually so that I could have a tiling window manager but still have all the normal desktop environment conveniences.
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?
The only reason I used manjaro and thus arch was that it had really nice I3, bspwm, and xmonad distributions.
It's very fun to rice a setup and make something worthy of posting on r/linuxporn.
I still do not understand why people like Tiling WM, maybe I should give it another try.
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 prefer cwm, it has tags, (virtual desktops), and it can be fully keyboard managed.
Switched to Hyprland about a month ago. Wasn't feeling it at first but after a few weeks I don't think I can go back.
I think Claude Code makes TilingWMs doable. I've always given up in the past because there have been reams of configs necessary to get to a fairly usable state, and I don't love reading manuals for desktop environments - but now it's all pretty easy to crank out.
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 think Claude Code is the crutch for being unable to go through docs.
Who wants to spend their weekends reading desktop environment docs? If that's your hobby, fine. I just want a working DE.
I believe it saves time, the documentation is available and easily digestible, and there's thousands of existing dotfiles to take from. I'd be disappointed to hear Claude couldn't do this.
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.
Who wants to read thousands of existing dotfiles?
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.