Dev Log: dreaming of scrolling wms

(ranty unedited post)

I’ve been deep cleaning and my years old arch install uptime was down to a single week(unemployable I know); so it was time to do a fresh install.

I used bspwm, a tiling wm, and while I love its stability and its bash control; I HATE HATE HATE “binary space partitioning” as a way to define a 2d space; I’ve seen concepts of scrolling wms, and so, given I’m breaking things to rebuild them it was time to check several of the scrolling wms.

# definitions for the noobs

wm: “window manager”, program that is started after logging-in that controls the position and size of canvases given to programs

window: a canvas owned by a program, x,y and width,height

move event: message sent from wm to window that changes x and y

resize event: message sent from the wm that changes the canvas and width and height

floating wm: “desktop metaphor” “your programs are papers on a desk” stupid default, users must manage x,y,width and height manually, overlap isnt prevent in the slightest and most workflow means “everything applications”

tiling wm: opinionated wm, that prevents overlap with resize events

scrolling wm: semi-opinionated wm that prevents overlap by move events using a large virtual desktop

hotkey deamon: program that converts key events (such as shift+printscreen) into arbitrary running code; (note wayland took TEN YEARS to finally make compromises on hotkey deamons being an EXTANT USE CASE)

bash-control: the wm accepts messages from cli, assuming user is heavily invested in a hotkey daemon workflow

# summery of meta-opinions

So reiterating my position, I hate floating wms, I’m very invested in hotkey deamons and bash control, I use a dual monitor set up with my main monitor being rotatable; while I tolerate tiling wms I know why they lost as you need something like css grids to define 2d layouts intuitively and no tiling wm as attempted this.

I believe tiling wms have compatibility issues with several programs because most people dev for floating wms, and first frame or tiny resize events can cause crashes.

#niri

Niri was stable and worked with dual monitors out of the box, the default controls seemed a little strange but I saw everything I needed.

The big failure was that my text editor didnt launch. Maybe for a pure work machine, but I’m not going to swap to all wayland anytime soon.

#hyprland

Tiling not scrolling.

Surprisingly good, sane defaults, I think the dev also used bspwm based off how it acted, I’m just not going to use a something so unstable that it has a compatibility list with login managers and theres drama around how to even package it, maybe if someone ships a distro around it.

The lack of stablity seems to be a thing.

#berry wm

So berry is even more bash-control then bspwm, so maybe I though I could make it work; its dual monitor support is highly exaggerated, where dual monitor are two tags, windows do not switch to a new monitor when you move them over, I didnt even try to see if you could “scroll” but I imagine it wouldn’t work well given that behavoir.

I did look into dxhd as an alternative to sxhkd and well… I think that may be quite interesting

#newm

Unusable with dual monitor.

#paperwm

It seemed fine, but I really really dont trust gnome or “tiling plugins”

#conclusion

I will be redoing my configs for bspwm in dxhd with a twist to see how it goes and maybe will try newm/hyprland on some sort of 2ndary machine