Share workspaces among all displays

[alexmohr]

hey, is it possible to share workspaces around all displays?
At the moment each output has it's own set of workspaces. Other window managers like Aerospace, hyprland, i3, etc. share all workspaces among the diplays, meaning if I have 3 displays and 10 workspaces rift will get 30 workspaces in total, whereas other window share the total amount of workspaces and get only 10.

If I'm understanding the rift architecture correct this isn't really something that can be changed easily, is there a way to achieve this with the command line tools?
If not could we get a command that moves all windows to a workspace on a given display?
If you're interested in such a feature I could look into developing this too.

[brianwk]

I could be wrong, but I believe the point of hooking into events with rift-cli and exposing the mach port is to enable such customizations. For example, instead of just calling workspace switch command, you can instead call a binary or script that interfaces with Rift.

The only thing missing is the command to move windows to another display. However you can do this with Accessibility API / AppleScript until it's native in Rift.

[brianwk]

i use sketchybar

[alexmohr]

That's great for you. But people do have different requirements and not everyone wants to tinker with sketchy bar. Coming from Linux myself its refreshing that you Don't need script powered bars like sketchybar and most of Mac OS just works.

Mainly I opened this not to discuss this with you but more to see how I could help @acsandmann to realize such a feature and if it's even possible given the rift architecture and how it works together with Mac OS spaces.

[brianwk]

Okay, no need to be rude, we both want the same thing to be honest... but I already spoke with the maintainer and he said the end goal is to expose the faculties to customize it how you wish. I also don't like that all 10 of my workspaces are on both displays,but I just live with it because the performance gain is worth it.

Also sorry about the brief comments, sometimes I'm doing other things and I don't realize how it comes across. But trust me we are both on the same team here....

[alexmohr]

I didn't intend to be rude, sorry if it came across that way 🙈
With the 3 screen I have in my office it's just not manageable anymore, but maybe that's just a 'me' problem 😄
Maybe it is better to build something on top of rift and extend the RPC instead of implementing it in the core of rift, I'm mainly curious about if this is something that the maintainer will do eventually or if it's worth the effort to spent some hours on.

[brianwk]

No worries but I did get super used to the Aerospace workflow, which allowed me to split up the spaces between multiple displays. It is annoying that I can no longer cycle through the spaces regardless of display.

[adamjhf]

This is my biggest pain point using Rift at the moment. Sharing workspaces across displays would remove a level of complexity for the user managing workspaces across multiple displays.

[brianwk]

Same to be honest. But I believe it's only because the integration points aren't there yet. I assume it's planned to be able to control every aspect through events / IPC.

[acsandmann]

i hear all of your concerns, but i think this will have "second" class support for some time. as in, this will be achievable via a more custom config that uses shell scripts/etc to have more dynamic behavior. you can actually create/destroy workspaces on the fly so with that and all the other hooks i think you could "somewhat" trivially implement what you guys are looking for. i will likely add a section to the docs of rift "extensions" where there are drop in examples for how to use it with sketchybar, skhd, and build more dynamic configs like whats wanted.

i think its relatively acceptable for it to be like this since the cli is fast enough for these to feel native and with examples provided that require little-to-no config it will be as close to first class as possible. (and you can actually execute scripts in the rift config so you don't even need skhd really).

please provide all feedback though. regardless of whether it is positive or negative i appreciate it and have been hard at work fixing all the bugs in rift(right now there is only really 1-2 issues that aren't fixed on main out of the 10 reported in the last week)

[brianwk]

biggest use case i can think of.... I like to put my productivity windows on the ultra wide at office, and everything else / preview apps (to look at the website / app i'm developing) on another screen.

how do you destroy the workspaces and create them? for example, i didn't see any event about the displays being changed. so when I unplug my display I have set a hotkey to reload sketchybar (not ideal)

also if I have an app rule that moves to workspace 2 and workspace 2 only exist on display X, will it just create the workspace on the current display Y?

currently all windows end up on one display. i can only move windows to the other display due to the patch i'm using.

I can't move all windows with hotkeys to another display without friction. Unless I use something like Hammerspoon to move the window outside of Rift, which is a pretty jarring experience.

also what crazy lunatic is testing the software 24/7 reporting all these bugs? 🤔

Anyways enough jokes... I'm thinking that if someone had a need to plug / unplug a lot from an external display Rift wouldn't work well for them. I already have mostly everything scripted out. I just need to combine the display moving into my scripts at this point, which doesn't seem "production ready" yet.

So to recap, for me to "script it out" using CLI events I need:

• Event for when the displays change
• Reliable CLI command to move the window to the other display. For example the current patch doesn't work with Zen Browser window. It's like it can't "move" the window the way it moves the other ones. It does eventually move when I switch between workspaces so I know it's possible to move it.
• Knowledge / documentation of how to add / remove workspaces to a display.
• Knowledge / documentation of how app rules will effect this. Will the app rule cause the workspace to be recreated?

With the missing pieces I'll be able to have 1:1 behavior of how Aerospace worked.