feat: add focus-on-demand mode for non-disruptive window focusing

[samholmes]

Add new focusOnDemand configuration parameter that changes AutoRaise behavior from continuous mouse-hover focusing to input-triggered focusing. When enabled, windows only gain focus when keyboard keys or mouse buttons are pressed while cursor is over the target window.

Key features:

• Mouse movement does not trigger focus changes (eliminates visual distractions)
• All input types trigger focus: keyboard keys, modifier keys, mouse clicks, scroll wheel
• Focus happens before input reaches application for seamless interaction
• Works between different applications and between windows of the same application
• Maintains all existing filtering logic (ignoreApps, ignoreTitles)
• Automatically disables timer-based raising when enabled

Configuration:

• New parameter: -focusOnDemand <true|false>
• When true, sets delay=0 automatically
• Expands event monitoring to include mouse and scroll events
• Compatible with existing configuration files

This provides a "focus follows mouse on input" experience that eliminates the disruptive constant window switching of traditional auto-raise while maintaining the convenience of not having to click to activate windows before typing.

[sbmpost]

@samholmes

Impressive. I had a quick look. At first sight looks like clean code and not an invasive change. I think some logic that is now in functions can be re-used by on-tick. When I have some more time, I will review your code more thoroughly. Thanks :-)

[samholmes]

One additional fix needed that I realized after putting this out is that there is a bug where the cursor needs to warp when using cmd+` to switch windows within an app. If the cursor doesn't warp, then the focusOnDemand causes the app under the cursor to be raised instead of the window being switched.

[sbmpost]

@samholmes

So perhaps warp must be automatically enabled then, with warpX and warpY set to sensible values.

Note that when ALTERNATIVE_TASK_SWITCHER is enabled, a window may receive focus for key combinations which AutoRaise does not intercept and warp doesn't work in these cases.

[samholmes]

@sbmpost Was shooting in the dark with the WIP commit while trying to solve it. I'll have to think on your comment a bit more.

[sbmpost]

@samholmes

Hi there. I was on a holiday for some time. The warp fix you made is intriging but quite a bit more invasive compared to the first commit. I am a bit hesitant to include it. How is all of this working for you? Are you using it on a daily basis?

[samholmes]

I have a branch ondemand-clean which dramatically evolves this concept. I'm using this as my daily drive for the week.

The ondemand feature or concept feels less annoying and more useful. I especially like the highlighting feedback that I added which lets me know which window is going to be focused on the next interaction (key or trackpad button press).

This concept may end up as a fork of the project.

The next thing I want to do with this concept is enable trackpad tap to raise/focus which would be a nice way to demand the window to the front without any interaction with the window (key or cursor button). This will require that one library that'll allow me to do this.

The other issue I'd like to resolve is managing restricted windows. Some windows like System Settings cannot be focused because they're restricted. I'm considering disabling the highlight for windows that cannot be auto focused. If you have information to share on how to handle these kinds of windows/problems, I'm all ears.

[samholmes]

Also, I believe I reverted the warp fix in my latest branch because it wasn't working well. I may bring back the cmd+` warp feature because that is also useful.

One improvement to warp is to have the cursor warp to an x:y that is relative to the previous cursor position. Instead of centering on the window, it may be more useful to remember the location of a cursor for each window. This way warping back and forth to windows is less intrusive with the cursor. You can switch back to a window and have the cursor position back to where it was when you left (so long as the window position hasn't changed since).

[sbmpost]

@samholmes

It seems you have many plans to take this tool to another level indeed, which is cool :-). Forking may not be a bad idea because I don't have that much time these days. And it allows you to explore your ideas without me trying to minimize the code base ;-)

• About System preferences not focusing: This was fixed in 5.4
• Reverting the warp fix I think was a good choice as the sequence of events is quite tricky.
• I once tried to draw a border around the currently focused window, but couldn't find an easy way to do it. It seems you have?

[samholmes]

Yes, I you can draw borders or rectangles using rhe NSWindow API. Checkout my branch ondemand-clean.