There is currently no way to control Mission Control from the command line, unless you're setting the Mission Control keyboard shortcuts. yabai could expose these notifications through its command line to make them scriptable (the current workaround being skhd --key ..., but that requires indirection and is not necessarily portable).
Working example, compile with clang -framework CoreFoundation -framework ApplicationServices path/to/file.c:
#include <CoreFoundation/CoreFoundation.h>
#include <ApplicationServices/ApplicationServices.h>
extern void CoreDockSendNotification(CFStringRef /*notification*/, void * /*unknown*/);
int main(int argc, char **argv)
{
CoreDockSendNotification(CFSTR("com.apple.expose.awake"), NULL);
return 0;
}
Known notifications are:
$ strings /System/Applications/Mission\ Control.app/Contents/MacOS/Mission\ Control
com.apple.expose.awake
com.apple.showdesktop.awake
com.apple.expose.front.awake
$ strings /System/Applications/Launchpad.app/Contents/MacOS/Launchpad
com.apple.launchpad.toggle
|Notification|Effect|
|-:|:-|
|com.apple.expose.awake|Toggle Mission Control|
|com.apple.showdesktop.awake|Toggle Show Desktop|
|com.apple.expose.front.awake|Toggle App Expos茅|
|com.apple.launchpad.toggle|Toggle Launchpad|
Do you think this is a useful addition, or does this fall out of scope?
One additional thought: if you could somehow hook into the listener for this on the Docks side, it would no longer be necessary to check whether Mission Control is active (if the scripting addition is installed).
Would this trigger mission control without any animation?
Would this trigger mission control without any animation?
No, but you can change the animation to a fade by activating the accessibility preference "Reduce motion". This takes the same time, but is far less in your face than the sliding animation.

I mean since this can kind of be implemented via applescript and binding it in skhd I would think it would be unnecessary? Or is there some sort of benefit I'm not seeing.
I mean since this can kind of be implemented via applescript
AppleScript does not expose these events. Best you can do is open -b com.apple.exposelauncher, but that only ever opens Mission Control, and cannot be used to open App Expos茅 or Show Desktop.
You cannot trigger these without binding them to keyboard shortcuts in the System Preferences. These cannot be set in your dotfiles and and thus cannot be used in portable scripts.
I mean since this can kind of be implemented via applescript
AppleScript does not expose these events. Best you can do is
open -b com.apple.exposelauncher, but that only ever opens Mission Control, but cannot be used to open App Expos猫 or Show Desktop.You cannot trigger these without binding them to keyboard shortcuts in the System Preferences. These cannot be set in your dotfiles and and thus cannot be used in portable scripts.
You're absolutely correct. I just double checked and most solutions are just sending keycodes via apple script. Good call and I'd love this kind of functionality since I use it often.
Sounds fine to me. Do you have an idea what these commands would be? I don't see which domain they would go under at the moment. Introduce a new one?
# should also focus selected space?
yabai -m space [<sel>] --toggle mission-control
yabai -m space [<sel>] --toggle show-desktop
# should also focus selected window?
yabai -m window [<sel>] --toggle app-expose
I'm not sure if the launchpad one needs to be a thing really. It's covered by open -b com.apple.launchpad quite nicely? It doesn't really fit in any of the categories.
One additional thought: if you could somehow hook into the listener for this on the Docks side, it would no longer be necessary to check whether Mission Control is active (if the scripting addition is installed).
Listening to "com.apple.dock.prefchanged" from NSDistributedNotificationCenter notifies when Dock preferences change (position / autohide / size etc.). I believe this can be used for slight improvements.
I can't figure out what notification center CoreDockSendNotification sends its messages to, sadly. Will require further reverse engineering.
I can't figure out what notification center CoreDockSendNotification sends its messages to, sadly. Will require further reverse engineering
It doesn't talk to any notification center. It uses mach_msg to talk to com.apple.dock.server - whatever that is.
Added the following commands:
yabai -m space [<sel>] --toggle mission-control
yabai -m space [<sel>] --toggle show-desktop
yabai -m window [<sel>] --toggle expose
All commands focus their respective entity before signalling the Dock.
We also listen for com.apple.dock.prefchanged and invalidate the size of all spaces.
Would it be possible to add a command to toggle the preview of mission-control?
To see this view:

Instead of this one:

Maybe like this: yabai -m space [<sel>] --toggle mission-control-with-preview
Or is this already working somehow?
The only way you can do that is by moving the cursor up there and back down. You can do that using cliclick quite easily.
yabai -m space --toggle mission-control && cliclick -r m:0,0
# you might need to sleep shortly for consistency
yabai -m space --toggle mission-control && cliclick -r w:10 m:0,0
does this feature require SA injection?
I'm currently quite happy with the functionality of yabai without the scripting addtions (coming from kwm and chunkwm).
But these commands look real nice.
Especially in combination with cliclick, thanks for that hint, @dominiklohmann. o/
This will require the scripting-addition to be installed for it to be able to apply the given space selector, so that it can trigger mission-control expose for the given space.
Without the scripting-addition installed, it should still be able to trigger expose for the currently actve space.
Most helpful comment
The only way you can do that is by moving the cursor up there and back down. You can do that using cliclick quite easily.