yabai: [Help Please] Cannot Open kitty Window on the Focused Display

yabai version: 2.3.0 macOS version: 10.15.3

I am using two external monitors. Then I open the first kitty window on monior-1 and say Safari on monitor-2. Then I make the mouse focus on safari (i.e., monitor-2). Then I hit cmd-enter to open another kitty window (in skhdrc, I set cmd - return : /Applications/kitty.app/Contents/MacOS/kitty --single-instance -d ~ to open a kitty widow). What I expected is to open this window on monitor-2 next to the Safari window. However, it is open on monitor-1, even though the focus is not there.

How can I open a kitty window on a monitor where the focus is on, instead of the monitor where the first kitty window is created?

Thank you very much!

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 25 (2 by maintainers)

Most upvoted comments

Thanks, @yanzhang0219 🙂 I updated my own script to use yabai signals which seems to work well. A few things to note about the newly launched kitty window:

Configuring

If the new kitty window is opened from an existing kitty window, my script will open the new window in the same working directory as the existing kitty window, much like what I’m used to with i3/urxvt on Linux.

Placing

Rather than moving the new window over to the focused display, I opted to:

  1. Check if the new window landed on the focused display and, if not,
  2. Re-insert (“warp”) the new window at the previously focused window (i.e., the one I launched the new window from).

That way, it’ll always split the previously focused window, instead of landing in a random location on the focused display.

Focusing

Regarding your comment above:

Actually I have tried [to focus the target window] already but it failed to focus the window.

That’s because you need to escape the yabai window ID variable within the signal command—i.e., \$YABAI_WINDOW_ID rather than $YABAI_WINDOW_ID—so that the variable’s name is resolved when the signal command executes, rather than when the script executes. If the variable name is resolved when the script executes, no value has been assigned to $YABAI_WINDOW_ID yet which simply causes the focus command to fail.

Try yabai -m config window_origin_display focused or yabai -m config window_origin_display cursor

@noperator try to use the script below:

#!/bin/bash

# Used by yabai and skhd
# Open kitty window in the current display instead of the display where the
# first kitty window was created.
index=$(yabai -m query --displays --display | jq .index)
yabai -m signal --add event=window_created action=" \
  yabai -m signal --remove 'testkitty' &&
  yabai -m window $YABAI_WINDOW_ID --display $index &&
  yabai -m display --focus $index" \
app="kitty" label="testkitty"
/Applications/kitty.app/Contents/MacOS/kitty --single-instance -d ~

Thank you.

Did you consider Kitty’s instance groups?

--single-instance, -1
   If specified only a single instance of kitty will run. New invocations
   will instead create a new top-level window in the existing kitty
   instance. This allows kitty to share a single sprite cache on the GPU
   and also reduces startup time. You can also have separate groups of
   kitty instances by using the --instance-group option

--instance-group=INSTANCE_GROUP
   Used in combination with the --single-instance option. All kitty
   invocations with the same --instance-group will result in new windows
   being created in the first kitty instance within that group

Then you can use an instance group per display:

cmd + alt - return : index=$(yabai -m query --displays --display | jq .index) && \
                    /Applications/Kitty.app/Contents/MacOS/kitty --instance-group=$index --single-instance -d ~

If Kitty Is focusing its most recently focused window before creating a new one, there’s nothing you can directly do about that.

What you can do instead, is save the index of the space you’re on before running the command to open a new Kitty window, and then move the focused window to the space you were on originally right after.

For debugging, try taking a look at the log files that yabai creates when ran in verbose mode, and look at the events that happen when you open a new Kitty instance.

Alternatively, you could also have open force a new application instance, but that may have unexpected side effects, as most apps are not built with this option in mind. To do so, run open -n -a Kitty --args --single-instance -d ~, for more info on open -n see man 1 open. I wouldn’t recommend doing this unless you have exhausted all other options.