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

[nikitabobko]

No description provided.

[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!

[RGring]

+1

[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!