Replies: 2 comments 3 replies
-
Hey, It's not possible to disable workspaces since they are deeply ingrained in the niri layout system. However, with the new event stream IPC you can watch for changes like the workspace moving to another output, and after I add by-id addressing to window actions, it should be possible to make a script that automatically moves all windows to the right workspace in this case. (Though, it will likely misfire if the output replugs itself upon DPMS or some such.) |
Beta Was this translation helpful? Give feedback.
-
Okay, cool. DPMS messing with stuff is fine, a price I'm willing to pay) I think for a simple script all that's needed is an IPC call for getting all windows per workspace (could probably run it through udev, or just in a loop, to avoid dealing with an event stream). Does something like that exist? I didn't find it in the CLI. By the way, niri is amazing, and I'm impressed by how polished your project is! Thanks a lot!)) |
Beta Was this translation helpful? Give feedback.
-
Hey!
I'm curious if there is a way to completely disable user-facing interactions with workspaces (i.e. rely only on the scrolling on one workspace per output).
I got pretty far by simply removing all the workspace related stuff from my configuration, but the one thing that remains is that when disconnecting an output its "workspace" gets moved to another output and (if you've removed all workspace keybindings) becomes inaccessible.
If this can be toggled somehow (e.g. merging workspaces into the workspace of the primary screen), that'd be great.
Why do this: I like simple things, and Niri's model is pretty excellent for that. Workspaces are an abstraction I don't need that takes up valuable "keyboard real estate".
If this isn't in Niri itself, I guess it might be doable through RPC interactions with Niri without changing the code?
Beta Was this translation helpful? Give feedback.
All reactions