macOS Sequoia about yabai HOT 48 OPEN

Edit: Also please try and look into why yabai can't inject the scripting addition anymore, I really am a turtle on it's back without yabai

This might just be the end of the scripting addition then. I have very little interest left in trying to circumvent all of these restrictions that they keep adding. The required effort is just not worth it to me personally anymore -- figuring out workarounds by myself is very time consuming.

I'll install Sequoia on a separate volume and look into things when I feel like banging my head against the wall, and take a brief look at the situation. If I can't make things work without having to put in substantial effort, I'll remain on Sonoma for a couple of years and so will this software.

Also edited the following into my first post, but maybe people haven't re-read it:
My initial assumption is that this is part of the AppKit framework and not a separate set of APIs, meaning that we will not be able to hook into this functionality from a third-party app in any meaningful way.

from yabai.

Just an update from #2331

from yabai.

Edit: Also please try and look into why yabai can't inject the scripting addition anymore, I really am a turtle on it's back without yabai

This might just be the end of the scripting addition then. I have very little interest left in trying to circumvent all of these restrictions that they keep adding. The required effort is just not worth it to me personally anymore -- figuring out workarounds by myself is very time consuming.

I'll install Sequoia on a separate volume and look into things when I feel like banging my head against the wall, and take a brief look at the situation. If I can't make things work without having to put in substantial effort, I'll remain on Sonoma for a couple of years and so will this software.

Also edited the following into my first post, but maybe people haven't re-read it:

My initial assumption is that this is part of the AppKit framework and not a separate set of APIs, meaning that we will not be able to hook into this functionality from a third-party app in any meaningful way.

Fair enough bro, you've been an absolute legend

from yabai.

Things should be working properly on the first Sequoia Beta now. (Adjustments likely required for second beta).

from yabai.

To switch spaces works on latest commit build :)

from yabai.

👀

from yabai.

Just updated - seems the only thing broken w/ yabai is sending windows to other workspaces (yet again).

from yabai.

I have 0 clue about how macos structures their apis but after testing the builtin snapping it feels great as it's smooth and responsive. I really hope they make this api open and exentsible for third party apps to use and I really hope yabai can use this api too.

A video to show how smooth this is https://imgur.com/a/seTzNUQ

Edit: Also please try and look into why yabai can't inject the scripting addition anymore, I really am a turtle on it's back without yabai

from yabai.

Another update from #2331

from yabai.

@cmdham You probably should be able to re-map these hotkeys as you wish in the Keyboard Shortcuts. (didn't install Sequoia though, can't tell for sure)

Nope, there is no option to do so that I can find (at least in beta 1).

from yabai.

Just updated - seems the only thing broken w/ yabai is sending windows to other workspaces (yet again).

Moving to other workspaces with skhd is broken for me aswell.
edit: scripting-addition failed to inject into dock.app

from yabai.

Macos Sequoia Beta 2, yabai seems to be working properly with skhd. Installed from head and updated the hash. I can confirm that I am able to switch and focus spaces, displays and have my focus follows mouse working. Haven't noticed any Dock crashes or any other crashes with yabai. Also the scripting addition loaded properly when reinstalling from HEAD.

from yabai.

A video to show how smooth this is

Wow, how you doing it with shortcuts?

You can use 🌐+Ctrl+Arrows and 🌐+Ctrl+Shift+Arrows

from yabai.

Current head version works perfectly on beta 3, yay!

from yabai.

This is the first place I came to check after seeing that as one of the features in the next update. Was hoping that'd give a more stable experience since it's becoming a first class citizen of the OS.

from yabai.

I figured them locking down the APIs portended them adding their own tiling thing. I might try the dev beta at some point and poke around.

from yabai.

I have 0 clue about how macos structures their apis but after testing the builtin snapping it feels great as it's smooth and responsive. I really hope they make this api open and exentsible for third party apps to use and I really hope yabai can use this api too.

A video to show how smooth this is https://imgur.com/a/seTzNUQ

Edit: Also please try and look into why yabai can't inject the scripting addition anymore, I really am a turtle on it's back without yabai

Looks promising

from yabai.

I'm not sure if focus follows mouse is dependent on the scripting addition, but at least everything in my yabai workflow is working on Sequoia. Only issues I have are with skhd.

It shouldn't be IIRC. Even without yabai there are apps that can achieve the same functionality without SIP disabled.

from yabai.

A video to show how smooth this is

Wow, how you doing it with shortcuts?

from yabai.

Surprise, surprise. Focusing space now does not work again on beta 2. No Dock crash tho.

from yabai.

Additional info: I try revert back to previous version of yabai (the one that crashed Dock.app when switching space) and nothing happened when I try to do anything (not even Dock.app crashing).

I think that offset values changed again in this version?

Edit: here's my Dock.app again → GDrive

Edit 2: Confirmed

from yabai.

Apple has introduced their own window snapping implementation. Let's see if this is backed by something more reliable than the accessibility API that is currently exposed to third-party developers.

I doubt it will be. Fully understand your decision to switch to something else. In past year's apple showed us, that they don't follow their own logic anymore. For example, cmd+first letter in question dialogs, or stage manager without shortcuts. By their logic, you need what they told you to need. You can't turn off most unneeded services, without consequences. Sad story, when you have no control over your system, and it is getting weirder and weirder. Funny how they advertise microsoft's chat gpt, the theater came to an end, at least with that : )

from yabai.

I'm not sure if focus follows mouse is dependent on the scripting addition, but at least everything in my yabai workflow is working on Sequoia. Only issues I have are with skhd.

It also seems that the yabai process is being stopped at some times, and a new prompt shows up warning about privacy when you wake from sleep.

from yabai.

Even if the new system doesn't work with Yabai (or anything else), presumably the existing workflow would still work, right?

from yabai.

If I start yabai, then uninstall and load the scripting addition it works for me.

(well, it did briefly then stopped and I can't reproduce it)

from yabai.

@cmdham You probably should be able to re-map these hotkeys as you wish in the Keyboard Shortcuts. (didn't install Sequoia though, can't tell for sure)

from yabai.

@pannxe Is it at least possible to entirely disable the feature, or did we just lose 8 combinations of keybinds for other use (Assuming we do not intend on using the feature)

from yabai.

@KennethHoff I don't think you can. The most you can do is disable edge snapping I think

from yabai.

🤦
Stop repeating Windows' worst decisions...

from yabai.

In macOS Sequoia, SIP must be disabled to be able to move windows between spaces.

What does "must be disabled" mean? SA currently requires partially disabling SIP (doesn't it?); Does Sequoia require fully disabling it?

from yabai.

In macOS Sequoia, SIP must be disabled to be able to move windows between spaces.

What does "must be disabled" mean? SA currently requires partially disabling SIP (doesn't it?); Does Sequoia require fully disabling it?

Only partial will do.

from yabai.

I just updated to Sequoia Beta 2 and can report that yabai is working, just like in Beta 1

from yabai.

Switching spaces not working on beta 2.

from yabai.

For my part, it appears yabai (head with AX permissions & SA) is apparently not getting informed of window destroyed events (whether window is closed by ⌘W, clicking red x, File -> Close Window, or indeed yabai -m window --close

[nor does it report seeing creates (just focus) for windows auto-vivified on application focus after such closes; for single window apps they appear retained in query while "gone"¹, and come back with the same ID ² - so this may be ~mostly accurate to how macOS does this now? ³ ;

(but when it was a second window, it goes away from query once closed, and a new second window has different ID, etc. but previous space occupied apparently remains allocated until application is hidden; for single window apps, yabai treating it "normally" again seems to require terminate and open)

(it is getting minimized, de-minimized, hidden, and at-other-close-time application-front-switched)

so in practice as I naively ⌘W & ⌘-Tab around I end up gradually halving my working space until I restart yabai (or force myself to quit/hide) [I also sometimes get windows drawing over each other; I haven't quite characterized when exactly - but seems related for sure]

no ~shade on not working perfectly on a beta, but I just wanted to post fair warning (for others considering the upgrade) given that the consensus appears to be all good

from yabai.

[possibly slightly more mysteriously, I just rebooted and ended up with first window I opened drawing on right half of screen

I did have second_child config;

or possibly just a case of the above; by the time I checked in that first-window which was a terminal -m query --windows only knew about that window, and I certainly never saw anything else paint, but maybe yabai saw something occupy that space and then didn't see it disappear (from the vantage point of event handling; if not query)]

from yabai.

I don't have any of these issues on my Sequoia install. (Both beta1 and 2 worked fine). Likely just macOS accessibility flakiness.

from yabai.

Working fine here too

from yabai.

Well I wonder why it hates me personally 🙃

I made sure that sa is definitely loading (It wasn't for a bit there cause I did the sha256 tagged sudoers fromt he wiki and didn't update that)

both /opt/homebrew/Cellar/yabai/HEAD-09a7b23/bin/yabai and (now to double check since its the symlink path in the plist) /opt/homebrew/bin/yabai are in the tccutil--list output

and seeing same behavior (of closed windows being treated as though persisting / consuming space in the layout)

from yabai.

I'd be pretty surprised if this were the issue¹ but in terms of possible self-inflicted wounds: my /private/var/select/sh is pointing at /bin/zsh and early in my .yabairc (after loading the sa though) I do emulate zsh to bring shell features back for my config

from yabai.

Well I wonder why it hates me personally 🙃

Okay well, after doing a reinstall¹ to pick up the couple new commits on head, daemonized yabai this time asked for both accessibility and screen recording and now seems less easily confused 🎉

(the screen recording prefpane knew about a yabai before ostensibly but apparently not at correct path?²:

)

from yabai.

hmm it seems like maybe removing that "invalid" (didn't open anything on right-click Reveal in Finder ; had broken icon ) and apparently redundant screen recording entry may have actually re-broken layout handling of window closes ?

(but -m query --windows output remains more correct than before)

(EDIT: but also removing the other, and doing --restart-service and following from prompt to enable it again seems to have fixed again?

EDIT 2: well ... (and maybe the "fix" of edit above was just confusion) what I am seeing now is actually:

1. window query output looks right pretty consistently
2. layout is still not responding to the close of windows via ⌘W (for both going from n to n-1 windows for same app; and/including going from 1 to 0 apps in which that does not effect an immediate termination)
3. but I think unlike before it does respond belatedly if I also terminate the program the windows belonged to

from yabai.

Okay, I am pretty sure my issue is caused by Arc Browser (on Sequoia, I don't believe it was an issue before upgrade)

(this makes some sense as Arc is a program with a pretty atypical concept of windowing (New Window (⌘N)) gives you clone(s) of windows that share state, but are expected to point at different tabs; and then for external links from another program it makes "Little Arc" windows that are AXSystemDialogue subrole (as the intended UX is that you either close it or push the button that moves it to the main window[s]). There can also be Incognito windows, and I just learned there is also a [New] Blank Window [^⌘N] that acts more like other browsers' concept of new windows )

what makes less sense is why/how it "infects" other programs - as I am seeing these "ghost window" misbehavior for all programs and all spaces when Arc is running even if it is hidden, or minimized, or has no open windows (according to my eyes and yabai query)

Arc does not have Accessibility or Input Recording or Screen Recording permissions

at core it is just a Chromium process (though perhaps unlike Chrome or most electron apps [I need to check more], it does apparently keep most of its --type=renderer and GPU process alive when there are no windows (and so no tabs) ~visibly open. that seems likely to be relevant - but I'll have to dig in more to how.

from yabai.

Actually— while I was attempting to verify / differentiate whether terminating Arc immediately restored sanity or if it was only after restarting yabai without Arc open— I instead (got confused because)— I hit a second case of inducing the behavior:

Pressing ⌘N in Finder (a second+ time / with a window open ) apparently now(?, on my machine anyway) opens new tab rather than a new window, but yabai is reacting like a new window was opened (which maybe on some level it was, but certainly yabai -m query --windows only believes there is one

so given these two examples, it seems like at core the issue may be related to programs doing something other than in the traditional sense opening a new window on Cmd-N

(Its definitely also possible that something else I am running is injecting confusion when it sees that, but I'm not immediately sure what that would be… because it could be several things 😅 ; I'll keep looking / doing ddx [and or get less lazy and actually put a build of yabai in a debugger to see clearer what the code sees])

from yabai.

But certainly whether or not the Finder issue repros for anybody else should be easy enough to test if you are so inclined

from yabai.

Also lest my description wasn't clear here have a video - the fact that each tab appears to be listed in the long-press-on-dock-icon seems possibly relevant (to suggest that there is some window-like object somewhere)

from yabai.

Sounds like some variation of #68

from yabai.

Sounds like some variation of #68

Since theres a known thing there, this probably isn't actually helpful, but

Its definitely also possible that something else I am running is injecting confusion when it sees that, but I'm not immediately sure what that would be… because it could be several things

I tore all the way down to

$ sudo launchctl list | grep -v apple 
PID	Status	Label
540	0	fans
-	0	com.vix.cron

 
$ launchctl list | grep -v apple  
PID	Status	Label
1441	-15	com.koekeishiya.yabai

and definitely Finder continues to behave like in above video.

(Frustratingly, it does seem like Arc's ability to infect other programs windows behavior is perhaps eliminated here at barebones runtime)

from yabai.

As I've been re-boostrapping stuff and trying to catch when issues start, I am now pretty sure https://contexts.co/ is the real culprit (~the actor who is getting confused by Arc and/or Finder tabs and then somehow ~generalizing behaviors to other programs; my intuition on how is something to the effect holding on to some sort of handle that is suppressing GC at the Obj-C/Swift runtime level or so)

--

Given that it is also very much in the business of observing windows, it was in fact one of my first suspects, but quitting it didn't (and doesn't, alone) seem to resolve weirdness

However it seems like quitting it, restarting Dock.app (!!), and then restarting yabai-proper and (thus) reloading the SA takes things back to behaving like before Contexts was opened.

Compatibility with this specific 3rd party app is obviously not in project scope for yabai and I can definitely live without it, so 🎉

I do wonder what it is doing that is managing to cause issues that outlive termination of its process though 🤔

(EDIT, FYI-for-nobody: since returning to default macOS ⌘-Tab after a long time was weirdly uncomfortable and I'm not ready to break myself of the habit [in favor of more efficient bindings] at the moment, I am giving https://alt-tab-macos.netlify.app/ a shot and glad to report it does not seem to cause any similar issues to contexts)

from yabai.