@oschonrock Hmm at least on sway it would be easy to work around the issue as you could assign some workspaces (1, 2, 3, etc.) to output one, some to output two (11, 12, 13, etc.), and then modify your shortcuts for switching workspaces to change workspaces on both outputs at once (i.e. `bindsym $mod+1 workspace number 1, workspace number 11` to switch to workspace "1"). And then configure whatever bar you are using to hide this.

Similar workarounds might exist on niri and hyprland?

@qwertviop @oschonrock This works for both Niri and Hyprland as well. You'd set the keybind for a script that calls

${compositor}ctl dispatch workspace 1
${compositor}ctl dispatch workspace 11

...

@ftranschel @qwertviop

It may be possible, but when I looked into it for niri, some potential conceptual blockers came up, eg:

niri has a dynamic number of workspaces

I haven't investigated hyprland as much.

@oschonrock @qwertviop Look into https://github.com/niri-wm/niri/wiki/for the necessary pointers.

WMs as opposed to DEs usually expect the users to customize their workflow themselves and lack accessibility in this regard.

However, my experience has been that a) you can get things not possible with DEs and
b) It's all the more fulfilling to solve the problem.

Edit: While Niri is unlimited scrolling you *can* have named workspaces and you *can* make them work in the way you laid out.

@ftranschel @qwertviop

Yeah, I am am expecting that, and wanting that. I'll write my own WM in C if that's helpful.

However, I may start with a simpler WM that niri, or hyprland and only progress to more complexity if required.

And also stay away from DMS/Quickshell whose memory leaks basically took down my machine (admittedly in their git HEAD version).

@ftranschel @qwertviop

I like the idea of QS, and the result is great. It's probably me. That's why reducing complexity might be a good step rn, so it's clearer where the issues are coming from.

The memory leak happened after I, slightly adventurously, installed qs-git from AUR, because the DMS was asking for more recent QS for "idle detect =>suspend" functionality.

Suspend worked, but when it woke up QS was consuming like 20GB.

I agree, could well be the QML using that feature.

@ftranschel @qwertviop

Overall memory consumption (before I installed -git version) from QS was also a bit irritating, >450MB?

Is that normal?

@oschonrock @qwertviop Depends on what you do with it obviously.

Running an app launcher, expose task switcher, bar, sidebar widget and some little bits is also 480MB for me, actually.

(Not Dank, though.)