Moving focused window from another space into current space
- Dominant language
- C
- Stars
- 29.6k
- Forks
- 750
- PR merge metrics
- No merged PRs in 30d
Description
Let's say you're currently working in space 1 and have an app in space 2.
When I use Raycast to open the app, mac by default switches me to space 2 instead of moving (or better, copying) that window to space 1. This forced context switch is annoying and I've been trying to find a workaround using the following:
Disable the auto space switching behavior.
```sh
defaults write com.apple.dock workspaces-auto-swoosh -bool NO
killall Dock
```
I then combine it with this script that moves a focused window in a non visible space into a visible space
```sh
YABAI_SCRIPT_LOG="$HOME/.config/yabai/.move_focused_window_to_space.log"
log() {
local message="$1"
echo "$message" >> "$YABAI_SCRIPT_LOG"
}
move_focused_window_to_space() {
focused_window_info=$(yabai -m query --windows --window)
focused_window_space=$(echo "$focused_window_info" | jq -r '.space')
visible_spaces_array=($(yabai -m query --spaces | jq -r '.[] | select(.["is-visible"] == true) | .index'))
log "Focused window info: $focused_window_info"
log "Focused window space: $focused_space, Display: $focused_window_space"
log "Visible spaces: ${visible_spaces_array[*]}"
is_focused_window_space_visible=false
for visible_space in "${visible_spaces_array[@]}"; do
if [ "$focused_window_space" -eq "$visible_space" ]; then
is_focused_window_space_visible=true
break
fi
done
if [[ $is_focused_window_space_visible == false ]]; then
echo "Focused window space is on non-visible space: $focused_space"
case "$focused_space" in
1) # etc (custom logic to move the window to the space you want)
yabai -m window --space 2
echo "Moved window from space 1 to 2."
;;
esac
fi
}
```
I hook up that script to these 2 events
```
yabai -m signal --add event=window_focused action="$HOME/.config/yabai/focus_windows/move_focused_window_to_space.sh"
yabai -m signal --add event=application_front_switched action="$HOME/.config/yabai/focus_windows/move_focused_window_to_space.sh"
```
It seems to work when I use Raycast to to open up different repos with my code editor Cursor (i.e. if a Cursor with repo A was on a different space, this script would move that editor into my current space).
However, it doesn't work with some other apps such as SpeedCrunch, Insomnium, Redis Insight, etc - possibly all other apps since opening the repos is using a special Raycast extension. The issue is that after I focus the window using Raycast, (I know it's technically somewhat focused because the iOS menu bar changes to show the context menus of the app I focused), and log the output of `yabai -m query --windows --window`, I get no results. If I log `yabai -m query --windows`, it shows no windows have `has-focus: true`. fwiw, the window that I tried to focus also has `has-ax-reference: true`.

Strangely, if I use Context3's search functionality to swap windows (essentially like AltTab), it does focus the window and my script then moves it to the current space. Sometimes I need to use Context3 to swap to the window twice before it successfully focuses it though.
Do you know why Raycast seems to have a softer focus than Context3? Is there anything else I can try to query for to find what window is "active" / has focus? Or maybe someone knows how to make Raycast trigger a "harder" focus?
One clue I noticed is that after swapping to Insonmium using Raycast, I couldn't send keyboard events - typing would result in beeps instead of inserting text into the query editor, where I last left the cursor. In contrast, using Raycast to swap to a different Cursor editor did focus it and typing would actually add text to the editor even if I can't see it (prior to implementing my script to move the window).
yabai-v7.1.14
Sonoma 14.6.1
M3 chip
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the move_focused_window_to_space.sh script and the yabai window_focused and application_front_switched signals. Reproduce the Raycast and Context3 paths on yabai v7.1.14, comparing query --windows --window and query --windows results. Done means identifying why the focused-window state differs and documenting a reliable query or event path for the affected applications.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- macos, shell
- Domain
- desktop, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100