Currently using Rift, migrated from AeroSpace

[brianwk]

Hello,

I'm currently using Aerospace but quite a few things about it annoy me. I wanted to tell you how I use Aerospace and if you think it is possible to use Rift instead. On Aerospace I have 9 workspaces. 6 of these workspaces are for different VS code profiles. On Aerospace, I wasn't able to get the different VS code profiles into their respective workspaces without using a Hammerspoon script

The same Hammerspoon script also addresses some issues with Sketchybar / Aerospace messing up after unlocking the screen, the system waking from sleep, or connecting/disconnecting another display.

Is it correct that Rift doesn't work well with multiple monitors and you can't move windows from one display to another with it currently? Since I use 2 monitors, and the monitor I hook up to is an Ultra Wide I am not sure if Rift can fit my needs. When connected at the office, the ultra wide monitor is used for all of my VS Code workspaces and also my terminals.

I did briefly run Rift with 1 monitor, and the way that the layouts work is a lot different than Aerospace it seems. I was changing focus on windows using ALT+H/J/K/L and it seemed that sometimes windows wouldn't go into focus that I saw underneath the other windows. One thing I dislike about Aerospace is that I have to run a Hammerspoon script, Sketchybar, SwipeAerospace, Jankyborder, and AutoRaise just to get it running in an enjoyable, optimal setup for myself. I also spent way too much writing that Hammerspoon script in that god awful Lua language because the issues I described were driving me insane.

I am also interested in Rift because of native full screen support. It sucks that I have to turn off "Displays have separate spaces" and I can't use full screen when I use two monitors, because Aerospace doesn't work very well if you enable it. Like right now I have it enabled cause I tried out rift, and when I go out of full screen Aerospace forgets what window was focused, etc after exiting full screen. Does this happen in Rift?

In any case, I'm trying to finish some projects then I will give Rift a more honest try. I do like Rust and I'm a lot more familiar with it than Swift. You may also find me contributing to the code...

[brianwk]

I just switched most of my config to Rift. The only thing that isn't switched is Sketchybar space integration. My Aerospace / Sketchybar has spaces on different displays but in Rift this doesn't seem possible?

For example, I have a Ultra Wide monitor and my built in Laptop monitor. The outer top gap should be bigger on the Ultra Wide monitor. I am not sure if it's possible to do this in Rift like it is in Aerospace. I haven't had a chance to look at the code and see if something is missing from the documentation.

Other than that, it seems quite good. One thing I noticed is that with multi-monitor the windows will start to flood onto my other screen if there are too many windows in one space. I noticed this when I first started it up with the default configuration.

I have quite a few windows open since I have about 6 different VS Code profiles. I had some other things to say but I forgot because I got distracted...

Now I remember... when I drag window from one monitor to another the window disappears. It might actually just be putting it on the space for that window but since my Sketchybar isn't indicating what the active space is at the moment it's hard to tell. In any case, how much should be handled by integration with mach server versus Rift core?

I got almost everything working but I can't seem to figure out how to make Sketchybar get the active virtual workspace from Rift. It only sends the event when I move my mouse from one monitor to the other. This makes me realize that it's referring to the actual MacOS workspace for the event, not the virtual workspace...

BTW I'm using Rift bleeding edge built from source. I just noticed another thing.... The Zen browser doesn't seem to "tile" correctly, but it tiled fine in Aerospace. It must have something to do with the tabs because when I open up Zen browser with no tabs open it's no longer as though I'm tiling ghost windows.

Another thing that annoyed me about Aerospace was that it used so much battery. I am curious if Rift will also drain my battery.

[acsandmann]

somehow not

Screen.Recording.2025-11-10.at.22.54.00.mov

[brianwk]

Stacking them on top of each other with Zen Browser open doesn't work at all. Here's a picture of the weirdness that happens here. (You can see Zen Browser in the right corner) Also you will notice the iPhone mirroring app window on this space for some reason, even though it's assigned to space 0.

Also as soon as I try to focus or click IPhone mirroring it changes to space 0.

When Zen browser is in the corner, if I move one of the windows the zen browser will correctly popout and it all reorganizes itself correctly.

[acsandmann]

Huh, that is weird. It is getting late so i can't work on this more till tomorrow but im really perplexed as to why you are encountering issues as i am not with zen browser.

i also reverted the query windows by spaceid commits as they were just not a good implementation and i have an idea of how to do it better itll just take some time. i hope these issues are not too much of a deal breaker for rift and i will definitely fix them (prs are welcome too 👀) but no hard feelings if you don't want to use rift.

also, if possible, could you open issues for each individual issue just for tracking purposes so i can slowly work my way through them.

[brianwk]

I'm quite tired myself. I didn't sleep much last night. I wish I had more time to dedicate to this; I will try to create the issues tomorrow I have some other stuff I have to finish.

If I could figure out how to get this to output debug logs that would be more productive as well.

Also as I mentioned I use Hammerspoon scripts. I'm used to Window Managers not doing what I want and then having to use something like Hammerspoon to enhance it. The hope is that I can either:

• Integrate my Hammerspoon stuff into a Rift feature as a PR
• Use the Mach server to make integrations for my VS code profiles, etc that doesn't need to use Hammerspoon.

For example I took my Aerospace Hammerspoon script and I changed it to work for Rift. Various things like moving my VS code profile windows to their correct space, etc. The WM can't do it because VS code changes the title AFTER it creates the window / loads. Most people just have one space for VS code, but I have 5. You can find my setup including Rift config in my dotfiles repository. The Sketchybar configuration needs a lot of improvement but I am very lazy when it comes to setting up my own system.

One thing I will say is that rift-cli is way faster, the aerospace CLI would take forever.

[brianwk]

I figured out why it's not logging. It was because the env var is RUST_LOG, not RUST_LOGS.

[brianwk]

I think I've created issues for most of the bugs I've encountered. If I notice anything else I will make another issue. Sorry if I create duplicate issues, it's not always obvious to me if the issue exists.

Are you familiar with the issues with native full screen? Basically when I put Zen Browser into native full screen to watch a video and then I went out of full screen, Zen Browser basically vanishes. I have to switch between virtual workspaces to get it to eventually pop back on the screen.

I'm probably going to create a Hammerspoon script to move my windows to the other display when I get to the office. I have a tab pinned to help me get it done quickly. Is sharing these Hammerspoon scripts helpful? I assume if I can figure out using Hammerspoon APIs, then it's possible for it to be ported to Rust. Of course it has to be ported in a way where it's a feature in Rift, and not necessarily the exact utility.

I may also take a stab at making a Hammerspoon script to band aid the wobbling that sometimes occurs.

The gesture swipe is real sensitive, I want to look at that too. Sometimes when I accidentally lightly touch the giant touchpad with my palm on the Apple Silicon Mac it will go to another workspace. I'm going to try to adjust the fingers to 4 now and see if that helps. I also have hotkeys setup for moving between workspaces so it's not the end of the world if I have to disable it for now when I'm using my laptop keyboard.

I may make a PR for making different set of virtualized workspaces per display, unless that's already being worked on by someone else.

[brianwk]

I rebooted my Mac this morning cause i was having an issue with the menu bar showing. Then I began to have all these problems with Rift. Well, it was because Aerospace was also running. Crap! I just wasted so much time, then I'm like well.... let me check .... because I had reverted back to the last known good git commit, and it was still happening. How embarrassing..

Also I discovered my Rust is now quite....rusty.... so will need to pick it back up again

[brianwk]

@acsandmann By the way thanks for your responses. Hopefully I can learn a lot from you and this project. (I've always wanted to code at a lower level)

[acsandmann]

@brianwk since you are a user of main, do you think its stable enough to cut a minor release so we can clear out all of the issues and then a major release once multi monitor stuff is 100% fixed.

[brianwk]

@brianwk since you are a user of main, do you think its stable enough to cut a minor release so we can clear out all of the issues and then a major release once multi monitor stuff is 100% fixed.

It would depend on how many users actually use multiple displays with Rift I suppose. Since it's definitely a lot of unexpected behavior with multiple displays. If you use DeskPad you can test it like you have an external monitor connected, although it's kind of a pain to use especially if Rift sends the DeskPad window to the DeskPad virtual display. You can make the resolution ridiculously wide if you want too, it will scale down inside the window.

I think of myself as a perfectionist so if it was my software I would consider not being able to drag a window from 1 monitor to another a blocker for release for a window manager. But maybe I have too high standards for software releases.

[brianwk]

I just updated to the latest main and it seems to be improved (the dragging of windows from one display to another). The only thing that stinks is that when you drag it to the other display it will not tile with the other windows on the other display. It also acts like a floating window and will be visible on every workspace until you dance around workspaces to correct it.

[acsandmann]

yeah i havent pushed a release because of these issues. im a bit of a perfectionist too

[brianwk]

I think it's really close if you can figure out how make the window tile when it "collides" with the bound of the other window (when dragging to another display) -- Believe me I know it's not easy I don't believe with current knowledge I could figure that out. (limited knowledge of MacOS programming in general)

With Aerospace I would move the windows using hotkey from one display to another since you are able to do that. So I don't recall the drag behavior in Aerospace.

[brianwk]

A window probably needs to have like a drag state or something I would imagine. So that when it's in this "drag state" the app rules don't get applied when it's entering the MacOS space on the other display. If Rift is ran with default config and no app rules will it have the same behavior? (Or maybe just no app rules)

[brianwk]

Anyways the progress in 1 week is pretty nuts. I don't know how you do it! Once the base is stabilized you can be on the road to new features.

[brianwk]

@acsandmann the PiP fix has an issue. When you start up Rift with PiP window active it will hide the window the PiP is playing from and also the PiP video window itself.

And also the display hotkey patch breaks the PiP functionality. The PiP window no longer floats.

[brianwk]

@acsandmann one thing i consider a pretty big flaw is that the app rules run when moving windows between displays (macos spaces) -- i think that they should only run when the window is created / app is launched. It seems like the issue here is that most of the logic is tied to a window "entering the space"

[acsandmann]

this will be a little bit of a complex fix because internally spaces are separate and dragging a window from/to is really like a window being closed and then opened in another space so im unsure of how to book keep this in a good way without it being a best effort hack which im not interested in..

[brianwk]

But right now with the display hot key patch I can move the window to the other display and then immediately move it to another workspace. The only thing is I don't know if it will move it to the workspace on the new display or the old display. Also I would be fighting against app rules. Isn't there a way to mark a window as "recently moved" or something so it doesn't trigger app rules?

Or instead of marking it as "moved" you mark the timestamp it was created. And if the timestamp is not like 1 second old, it won't activate app rules.

Are you saying that when the window is moved the window ID changes?

So here's the thing about app rules I just thought of.... if we have a configuration where the virtual workspace doesn't exist on the target display, then it would just keep the app on the active workspace. So the bookkeeping is the app rules.... For example I have an app rule that sends a window to space 1, but space 1 doesn't exist on the display that the window is on. So it doesn't do anything. Or if the app rule is scoped to the display UUID it won't run and execute on the other display. I believe that's how Aerospace handles this.

I think the most important thing is avoiding undefined behavior. Does this not solve the issue of creating undefined behavior? In documentation you make it clear how it behaves with "global app rules" versus "per display app rules" so there is no confusion.

Sorry for braindump hopefully something I said is helpful...

[brianwk]

@acsandmann I got a lot of respect for you. I've been trying to figure out how to make a PR to configure the font face for the Mission Control. Spoiler alert: I never figured it out. Apparently getting a CGFont from a text string is black magic...

Toll free bridge? Who comes up with this stuff?

[brianwk]

@acsandmann I would say that you can probably cut a release after the patches are tested some more. The problem is most users typically won't report that it's working fine like I will. They will only report when it's not working. So probably wait and see if any other issue reports come in I suppose. These are the patches I'm using:
working_directory.patch

(Not to say there aren't some issues still, but when you are making a MacOS window manager there will likely always be quirks.)

Problems fixed:

• The windows no longer all go to one display when I plug in my display. Also when I unplug and replug in the windows stay on the respective display they were on previously. I assume this is MacOS doing this and not Rift but I am not sure.
• You can click and drag (most) application windows to an external monitor, or use CLI command to send to external monitor. In my case I wrote a script to send to "next" monitor that wraps around.
• I haven't experienced the workspace locking up today. I purposely changed my workflow a bit (switching between virtual spaces) instead of using two monitors to see if it would come up.

I'm still having the same issues with Brain.fm, Finder windows, iOS simulator, and Zen Browser. I was looking at the paid solution "Komorebi for Mac" and I noticed they have something similar to app rules and Zen Browser is set to not be managed at all by the software. (Don't worry, I don't plan to switch to Komorebi) -- Just saying that other MacOS window managers have an issue with these windows too.

I am not just testing Rift sometimes, I am using it the entire time I'm on my computer. And since my work relies on the computer I am testing it a lot.

[brianwk]

Currently I'm using commit cfedd22
And I have 3 patches applied:

• floating window fix
• workspace lockout fix patch (non-heuristic)
• move window to display hotkey patch

If I attempt to migrate to main, everything breaks and I have windows floating all over the place.

diff of working directory attached if it's helpful (not sure if it's different from the previous one) wd.patch

[acsandmann]

I'm actually experiencing an issue in my patched version where Zen Browser thinks it's a floating window and it appears on every workspace. But on main branch I will have WezTerm and other windows floating too. When I restart Rift it goes back to normal.

floating windows are per workspace. if its always there that means that it isnt managed or that it isnt getting hidden or something like that

[brianwk]

I just had another issue that i never had before using Rift. My entire computer input locked up and I was unable to type. I had to hard reboot my Mac.

[brianwk]

I may have been using the wrong version of rift because MacOS somehow messed up my PATH variable. I unlinked the Homebrew version of Rift to ensure I'm using the correct version when I run rift

[brianwk]

I reset to head again in case I was using the wrong version somehow. Since I switched back and forth between two terminals, it's possible the PATH on one terminal was different or something.

Did you make any further progress on the command to switch a window to another display?

[brianwk]

I'm not having the issues before I rebooted on head so it's possible when I was applying the patches something got messed up.

[brianwk]

I should have known when the windows started floating around like crazy that something was amiss I guess.

It's working so good on latest main branch now. I think that you may be on the path to creating the best window manager for MacOS.