Feature request "focus follow mouse" / "mouse follow focus"

[nikitabobko]

• focus follow mouse
• mouse follow focus Feature request "focus follow mouse" / "mouse follow focus" #12 (comment)

[nikitabobko]

Okay, since I don't use this feature, and I don't understand why people use it. What are the workflows of people who use it?

There are several controversial questions:

• How should users be able to access the menu bar? (in macOS, the menu is not within window borders) Once the mouse is moved out of the window border, the focus changes
• If the cursor is within the currently focused window bounds, and I change focus with keybinding. Then I slightly move the mouse keeping it within the previously focused window, should the window receive the focus back? Or does the focus change only once the mouse crosses borders?
• How floating windows should be handled? Are they prioritized over tiled windows? How to choose between several overlaping floating windows? It looks like macOS doesn't allow to check "the stack" of windows, so I can't just pick the most recent

[nikitabobko]

https://www.reddit.com/r/i3wm/comments/141mkdy/comment/k84qrp7/?utm_source=share&utm_medium=web2x&context=3

[BrianGilbert]

+1 for this feature, it will be hard for me to leave yabai without this

[smallstepman]

example workflows

• when using web browser using touchpad, and I'll want to change focus to the text editor - it's faster to change focus with focus follow mouse feature when I already have my hand on touchpad, than press CMD+ (especially if the window that I want to focus is further away, eg Id have to do CMD+left+left+up).
• I want for example click play on a song in Apple Music while having focus on some other window. When using touchpad and without having FFM, I need to mouse-click on the window to first activate it before I can use it, meaning, without FFM I need to click twice to actually play the song

[fmasa]

I'll describe my use-case as well:

• How should users be able to access the menu bar? (in macOS, the menu is not within window borders) Once the mouse is moved out of the window border, the focus changes

I'll rarely use the menu bar - I either use shortcuts or if make my window fullsize if I need it

If the cursor is within the currently focused window bounds, and I change focus with keybinding. Then I slightly move the mouse keeping it within the previously focused window, should the window receive the focus back? Or does the focus change only once the mouse crosses borders?

I use focus follows mouse + mouse follows focus in i3/sway/yabai, so the cursor moves to the center of the focused window if I use the keyboard to change focus.

How floating windows should be handled? Are they prioritized over tiled windows? How to choose between several overlaping floating windows? It looks like macOS doesn't allow to check "the stack" of windows, so I can't just pick the most recent

I don't know the solution to this one, but I would personally be fine with this working any way (or not) with floating windows as I don't mind clicking these.

[acheronfail]

This could be a good reference for implementing it: https://github.com/sbmpost/AutoRaise

[mike1808]

I use this feature a lot in i3. My most use case for copy pasting. I select a text with a mouse on workspace A, move my mouse to workspace B and paste there. I don't need to click on a mouse to focus the window buy just hit the copy and paste shortcut.

[paulodiovani]

This is how I use it, hope it helps.

As a web developer, I use the mouse most of the time for testing applications, and since it is always on reach, I got used to the mouse for switching window when:

1. I have more than one window on the same workspace
2. I go back and forth to my dropdown-terminal to multitask or copy/paste text
3. I switch to a window in another monitor
4. I switch to another monitor to open an application there

Here are your answers from my perspective.

• How should users be able to access the menu bar? (in macOS, the menu is not within window borders) Once the mouse is moved out of the window border, the focus changes

• With Sway/i3 and Yabai, the menubar (or whatever bar) does not steal focus, ever. So it is very much possible to use it while focus follow mouse is enabled.
• I believe that is the default behavior of macOS menubar even without focus follow mouse. When clicking it, the current focused window remain focused.
• If the current focused window is floating, leaving the window and moving the mouse over the (empty) desktop does not make it lose focus
  • Clicking on the desktop might make it lose focus however, if the user have file/app icons on desktop (I don't).
• If the layout is horizontal (one window on top of another) then it is only possible to access the menubar menu of the top window, since the mouse must hover over it to reach the menubar.

• If the cursor is within the currently focused window bounds, and I change focus with keybinding. Then I slightly move the mouse keeping it within the previously focused window, should the window receive the focus back? Or does the focus change only once the mouse crosses borders?

• Yes, the slight change on the mouse gives the focus back to the window below it.
  • As @fmasa suggested, using it in conjunction with mouse follows focus remediates this issue
  • I believe some WMs have a deadzone or minimum motion to prevent accidentally moving the focus away, but I never tested it.

• How floating windows should be handled? Are they prioritized over tiled windows? How to choose between several overlaping floating windows? It looks like macOS doesn't allow to check "the stack" of windows, so I can't just pick the most recent

• Just like tiled windows. If the mouse move inside its boundaries they gain focus. When the mouse leaves them, the window below gain focus.
• If I do remember, in Sway, floating windows are always on top. With Yabai they might move behind a tiling window, which can be annoying since it becomes out of reach.

[asr-rbx]

+1 for this. The key use case for me is to be able to switch to windows on multiple monitors for copy paste from browser to editor.

[wsny]

+1 for adding this in. In the meantime for anyone wanting this functionality, I found that https://github.com/sbmpost/AutoRaise gets the job done.

[hirenp]

Pretty please. This seems like a no-brainer to have. You either don't use mouse at all and if you do, having this feature is quite a blessing.

[matthiasdg]

My use case is simply having the mouse follow me to the active screen; can't do everything with keyboard and this saves time compared to dragging it all the way to the next screen. Luckily AutoRaise also covers this with its warping!

[freeqaz-figma]

To add context on why this is useful:

• I have dual monitors
• I'm coding in my IDE and I click a button to run my app (workspace 1)
• I use my keyboard to snap to my web browser running on my second monitor (workspace 2)

If I need to click a button on my web browser I now have to drag my house across potentially 2 full monitors. It's not the end of the world but it's annoying.

Would anybody mind sharing their AutoRaise config btw?

[freeqaz-figma]

This my config (stored at ~/.config/AutoRaise/config):

#AutoRaise config file
pollMillis=50
delay=2
focusDelay=2
warpX=0.5
warpY=0.5
scale=1.5
altTaskSwitcher=true
ignoreSpaceChanged=false
invertIgnoreApps=false
ignoreApps=""
ignoreTitles=""
stayFocusedBundleIds="com.apple.SecurityAgent,..."
disableKey="control"
mouseDelta=0.2

I wish that it wouldn't focus my background "stacked" windows which sometimes I get surprised by when I mouse over them. I'd still much rather have this in AeroSpace itself to "focus" windows in the workspace when I switch. But for now this hack works fine.

I can't get it to auto-launch with AeroSpace in my config properly, so I just run this in a terminal. Good enough, but if somebody knows how to make it launch in the background that would be pretty cool too!

[amuricys]

I second everything that was said above, and I'd add that since creating a new window doesn't automatically focus it (I often do cmd + shift + enter to open a new terminal and then immediately start typing because i have a command in mind), after a window is created I have to look for where it is, THEN click - so 2 "tasks". I want to have to only look for where it is, fling my mouse over there and start going. It's ridiculous how often I send a mistaken slack message whose content is ghci instead of running it because i forgot to click on the new window which i obviously want to focus immediately after creating (i tried to hack around this using list-windows and matching on any newly created window in on-window-detected, but because there's no metadata to the windows regarding which was most recently created, this is impossible).

[lucax88x]

If you want to have "mouse follow focus" feature from autoraise remember to enable altTaskSwitcher=true and the warpX and warpY at 0.5 or it won't work.

[nikitabobko]

Update

Since 0.13.1-Beta, AeroSpace introduces:

• move-mouse command https://nikitabobko.github.io/AeroSpace/commands#move-mouse
• on-focus-changed/on-focused-monitor-changed callbacks https://nikitabobko.github.io/AeroSpace/guide#on-focus-changed-callbacks

The combination of these two allows to have very configurable "mouse follows focus" workflow (but not vice-versa yet):

on-focused-monitor-changed = ['move-mouse monitor-lazy-center'] # mouse lazily follows focused monitor (default in i3)
# or
on-focus-changed = ['move-mouse window-lazy-center'] # Mouse lazily follows any focus (window or workspace)

Consider sponsoring the project to see more cool stuff! https://github.com/sponsors/nikitabobko

[joefiorini]

@nikitabobko Following your call to action I went ahead and sponsored, hoping maybe it'll help you be able to work on this.

How should users be able to access the menu bar? (in macOS, the menu is not within window borders) Once the mouse is moved out of the window border, the focus changes

This happens to me in yabai; I usually just cmd+tab back to the window that previously had focus once I reach the menubar. Not ideal, but it's an acceptable tradeoff. Probably worth noting that I personally do not use "mouse follows focus" as I sometimes switch to a window just to use a keyboard shortcut and don't want the mouse jumping around on me.

[Calvin-Xu]

Adding to this discussion, I also used yabai and now Amethyst, and find focus follows mouse invaluable. I have resigned using the menubar with mouse and instead Cmd Shift /. It is the tradeoff I have accepted. I also do not use mouse follows focus.

yabai was quite finicky when I used it, and I appreciate Amethyst for playing nicer as an app, which happily seems to be what this project is aiming to be.

[nabahool]

• How should users be able to access the menu bar? (in macOS, the menu is not within window borders) Once the mouse is moved out of the window border, the focus changes

In yabai you can assign a key which temporarily disables "focus_follows_mouse" when held. From yabai docs:

Focus follows mouse is disabled while holding the mouse modifier key so that you can access the menu bar easily.

[milch]

Is it possible to ignore certain apps/windows for the on-focus-changed event? I set it up with the move-mouse command to implement focus follows mouse. With yabai I was able to except iStat Menus from this since it doesn't play well with the option:

yabai -m rule --add app="(^.*iStat Menus Status.*$)" mouse_follows_focus=off manage=off

But I don't see a way to do this in Aerospace