Make it focus without bringing window to the front

[samholmes]

Similar to ctrl+opt+click, I'd like to config this tool to focus a window without bringing it to the front of all other windows. The primary use-case for this tool for me is to focus on a window for quick access to keyboard shortcuts for that window. The focus without raise feature could be instant or customized to a specific delay.

If I want to bring the window to the front, then it would be nice to make this tool bring the window to the front after 500ms of no cursor motion. This way I can move my cursor anywhere without raising windows but focusing instantly on windows. Only after stopping my cursor on one window will the window be raised. This is the ideal UX I'd like to achieve. Is this doable?

[dreeves]

Beautifully said and I think you're absolutely right that this is the ideal behavior. It's how it works in Linux too! (They call it focus-follows-mouse + auto-raise, where the focus-follows-mouse part is always instant and the auto-raise delay is configurable, including the option to not auto-raise at all.)

Unfortunately @sbmpost has looked into it and concluded that Apple just doesn't expose the ability to focus without auto-raising.

If anyone thinks of some clever way to somehow make it happen, that would be amazing.

PS: Dup of #7

[sbmpost]

@dreeves thanks for covering this one :-) And indeed it is true this cannot be done ATM.

[sbmpost]

@dreeves @samholmes I suggest we leave this issue open, so others can take note of this as well. Thoughts?

[dreeves]

Sounds smart! I'd even advocate for adding notes here about why exactly it's impossible and to solicit ideas on conceivable ways to work around Apple's limitations. I'm guessing it's baked deep into the OS and is truly hopeless but who knows!

[BenJackGill]

This describes the desired functionality very succicntly:

focus-follows-mouse part is always instant and the auto-raise delay is configurable, including the option to not auto-raise at all

Perhaphs a work around could be to instantly auto-foucs, but put on a large custom delay on the auto-raise. The delay could be so large that infact it operates similar to having no auto-raise at all. For example, a Delay setting of a few hours or days that only affects the auto-focus part and not the focus-follows-mouse part.

Is that possible?

I tried changing the Delay setting in the config file to a large number (i.e. 100000000000) to test this theory, but it had no effect.

Is the current Delay setting supposed to affect both the focus-follows-mouse and auto-raise at the same time? Because if you could seperate out those Delays (one delay setting for focus-follows-mouse, and one delay setting for auto-raise) then this workaround might suffice.

[sbmpost]

@BenJackGill
The problem is that OSX needs to be instructed to raise the window in order to focus it. As such the two always come together. There is no other way to focus a window.

[fredngo]

Ugh, this is exactly the behaviour I'd like to see, super bummed that it seems not possible right now!

[sbmpost]

@samholmes @fredngo @dreeves @BenJackGill

I experimented more and used some code from another project. It would seem that with a private Apple API, this can be implemented. But note that this is very low level and may break easily in future OSX versions. I am therefore keeping this in an experimental branch. It may never make it to master, but I figured you might be interested. It can be built like so:

g++ -O2 -Wall -fobjc-arc -o AutoRaise AutoRaise.mm -framework AppKit -F /System/Library/PrivateFrameworks -framework SkyLight

[dreeves]

Ooh, exciting! I switched to branch 7-47-focus-without-raise-experimental and built it (confirming that it's v2.8 running) and that works to have focus-follows-mouse without auto-raise! But what I'm really pining for is immediate focus-follows-mouse with 500ms-delayed auto-raise.

So tantalizingly close now! <3

[sbmpost]

@dreeves ok! Thanks for the feedback. Out of curiosity: what is the difference between raising a window after 500ms or focusing it first while the mouse is hovering over it? I cannot imagine someone to move the mouse while simulatiously using the keyboard to access that window.

[Laaarge]

@sbmpost I think I see what he wants: with 500ms autoraise, you wouldn't have any problems with windows raising while moving the mouse ect, and you also (with immediate focus follows mouse) not have any issues of your first keypresses being registered in the wrong window.

I think that's a good idea, although I'll try focus instantly follows mouse(without raise), it may be enough for my usecase.

[sbmpost]

@Laaarge

and you also (with immediate focus follows mouse) not have any issues of your first keypresses being registered in the wrong window.

I see, yes that could be it. Thanks.

[dreeves]

Exactly right. The default 40ms delay kinda drives me crazy when I'm a bit too slow with moving the mouse across my various displays. But any longer and it would be too annoying waiting for the focus to change. Immediate focus change with delayed autoraise elegantly gets the best of both worlds!

PS: See also #7

[Laaarge]

So I've been using this and it is great, it fits my needs much better than traditional AutoRaise.
However I had 2 problems:

• When getting a system popup window (for example: deleting something, closing a running terminal, macOS asking for a password) the popup would flicker, (and be harder
• When trying to access the small popup menus of brave extensions, they would disappear as soon as I move the mouse after clicking (to get the menu open), it would close the menu… not Ideal

But:
for better or for worse, I have the Noobest solutions of all:
I removed lines 138-154 (because verbose logged >>>>>>>>psn equals<<<<<<<<<)
And that has fixed both of my problems… Lol

I do have a remaining problem:
In both of those situations, verbose still logs in a loop Activate and focus without raise, $window info$,
which I don't think is the intended behavior

PS PS: I'm not pushing this since it's such an ugly fix, but if someone wants to take a bite at it, I think this is a great starting place (and I'm going to look into doing this properly)

PS PS PS: I notice that AutoRaise's %CPU (in Activity Monitor) is much higher when moving (fast) around in 1 window, then switching focus very frequently (and even higher than when flickering popup menu) (haven't tested it on main branch though)

Thanks a lot for this App!

[sbmpost]

@Laaarge
Thank you for your feedback, always appreciated :-)

I pushed a new version. It logs only if the verbose flag is enabled.
I also made some changes in the way it finds the window under the mouse.

I removed lines 138-154 (because verbose logged >>>>>>>>psn equals<<<<<<<<<)

These lines handle the situation where you have 1 single app with multiple windows and you move the mouse between those windows. I think with my latest changes, at least the popup flickering should be gone (leaving lines 138-154 intact). The price however is that any window that is smaller than the window below it, will keep the focus. I am not sure if this is better/worse than the previous situation.

When trying to access the small popup menus of brave extensions, they would disappear as soon as I move the mouse after clicking (to get the menu open), it would close the menu… not Ideal

Not sure about the brave extensions. For these it would be interesting to see what the window title of the popup is:

if (verbose) { NSLog(@"focus without raise, %@", _windowTitle); }

Of course you now have to enable verbose logging for that ;-)

I notice that AutoRaise's %CPU (in Activity Monitor) is much higher when moving (fast) around in 1 window, then switching focus very frequently (and even higher than when flickering popup menu) (haven't tested it on main branch though)

The main branch has the same behaviour. Because for each mouse move we determine the window below the mouse and see if it needs to be raised or not. If you merely switch focus, then these actions are executed just once. To reduce CPU, the polling interval can be increased (see the top section of the AutoRaise.mm file), but that will reduce responsiveness.

[Laaarge]

@sbmpost
'twas nothing, thanks for the quick reaction (and work!) : )

These lines handle the situation where you have 1 single app with multiple windows and you move the mouse between those windows.

Oh ok (strangely, it didn't run into an issue with that, but testing it now, yeah it didn't switch windows within 1 app)

at least the popup flickering should be gone

Yup confirmed

The price however is that any window that is smaller than the window below it, will keep the focus. I am not sure if this is better/worse than the previous situation.

I'll keep an eye on that, but it's something that definitely won't be frequent, if it even happens to me: I can't think of cases where that would cause a problem… but that situation definitely exists :'(

Not sure about the brave extensions. For these it would be interesting to see what the window title of the popup is

it's a bit weird, it doesn't give anything else than the tab name, and I saw a few different behaviors for this, but it seems now that it works without problems the latest commit (popups only disappearing if the browser loses & regains focus).
verbose only logged me this when I was having issues…
but I don't think it's worth looking into, as it seems fixed (though if you want to, do ask me, as there is more info)

… 18:04:29.518 AutoRaise[…] focus without raise, New Tab - Brave
… 18:04:29.518 AutoRaise[…] >>>>>>>>psn equals<<<<<<<<<

[sbmpost]

@dreeves @Laaarge @samholmes @BenJackGill @fredngo
So it would seem I have implemented the holy grail then ;-)
Check out the latest version of this branch and run this:

make clean && make && ./AutoRaise -delay 25

(don't forget to close already running AutoRaise instances)
Of course you can play with the delay to suit your needs.
And to disable the raise, simply set -delay 0

[dreeves]

This is amazing! Nice work! It's working beautifully for me. Now I'm wondering if there's any possible use case for it to ever not work this way...

[sbmpost]

@dreeves @Laaarge @samholmes @BenJackGill @fredngo
I have done a few more fixes and tweaks so you might want to update again.
If nothing else too serious pops up, I will now leave this branch alone for a while.

I suggest to keep this issue open for future reference and additional feedback.
Thanks everyone :-)

[dreeves]

I'm on the latest as of now and it's smooth as butter. I'm really, really happy with this!

I'm also really curious to hear if there's some argument or use case for the focus-follows-mouse part to ever be non-immediate.

(Maybe one reason is that you don't trust it to keep working in future macOS versions? That would be a tragedy.)

PS: Note that this GitHub issue is a slight misnomer now (#7 characterizes it more fully) but that's fine to keep the discussion here.

PPS: We know there are some people like @Laaarge and @samholmes and @fredngo who want focus-follows-mouse without autoraise at all. Maybe it would make sense to overload the -delay option like so:

• delay = -1 (aka infinity) means no autoraise, only focus-follows-mouse (which is instant)
• delay = 0 means focus-follows-mouse and autoraise both happen instantly, no delay
• delay = positive number means focus-follows-mouse is instant with subsequent autoraise happening after the given amount of delay

I.e., focus-follows-mouse could always be instant and the delay for autoraise, including whether it happens at all, could be specified by the -delay parameter.

PPPS: Just realized I'm proposing something pretty similar to what @BenJackGill proposed earlier in this thread but with "-1" as the stand-in for "infinity" rather than "100000000" or whatever. (Also I'm suggesting that it never makes sense to have a delay on the focus-follows-mouse part, only the actual autoraise.)

[sbmpost]

@dreeves

I'm also really curious to hear if there's some argument or use case for the focus-follows-mouse part to ever be non-immediate.
(Maybe one reason is that you don't trust it to keep working in future macOS versions? That would be a tragedy.)

Exactly that :-)

Maybe it would make sense to overload the -delay option

Currently in this particular branch it works like this:

• delay = 0: no autoraise, only focus-follows-mouse (which is instant)
• delay = 1: focus-follows-mouse and autoraise both happen instantly, almost no delay
• delay = positive number means focus-follows-mouse is instant with subsequent autoraise happening after the given amount of delay

So very close to what you are proposing actually ;-)

However I see your point that if this would go to master (unlikely, because of aforementioned reason), then the delay should probably work similar to what you described. Note that currently in master a delay equal to 1 means instant raise.

[samholmes]

I'm in the -delay 0 club because I think if I want to raise a window, I will click it. How do I bundle this command AutoRaise -delay 0 into an app bundle?

[sbmpost]

@samholmes

How do I bundle this command AutoRaise -delay 0 into an app bundle?

You probably don't ;-). To pass arguments to the app bundle version you can use a configuration file (see the README).

[git-rz]

I have built the branch and run with -delay 0. I do not ever want auto-raise. Just focus.

I am observing that the menu bar at the top of the screen is changing apps as the mouse pointer is still in motion and crosses other open apps. This is no good. How is one supposed to access the bar when there are other windows in the way? The answer is Ctrl-F2, but most users probably don't know that. Even so, accessing the menus only by keyboard is then a sub-optimal experience.

The original requirement in this thread specified the mouse needs to come to a stop before triggering focus. That made sense, and should enable menus access. But that does not seem to be happening, and that makes the branch difficult to use for the original use case: Just focus, no raise.

Recommendation is to either

• detect when the pointer stops moving before focus, or
• allow for delay before auto-focus again

Accessing the menu bar is the major use case for the focus delay.

[fredngo]

• delay = -1 (aka infinity) means no autoraise, only focus-follows-mouse (which is instant)

I'm in the delay = -1 club for sure. I don't want it to ever auto-raise (despite the name of this app, lol). I just want it to focus-follow-mouse immediately. I guess this is the behavior I just got used to working on old Unix machines. 😆

[fredngo]

• delay = 0: no autoraise, only focus-follows-mouse (which is instant)

Oops, just saw this -- I guess I'm in the delay = 0 club instead then.

[fredngo]

I am observing that the menu bar at the top of the screen is changing apps as the mouse pointer is still in motion and crosses other open apps. This is no good. How is one supposed to access the bar when there are other windows in the way

Yup, finally got around to building and running the experimental setup. Works well except for this one problem!

[fredngo]

By the way, I went ahead and created a homebrew formula for the experimental branch which makes it way easier to compile/install/etc for most folks!

https://github.com/fredngo/homebrew-autoraise-experimental

The HOWTO is in the README, but here's a synopsis.

Don't forget to uninstall the original homebrew formula if you already had it installed before:

brew uninstall autoraise

Update your ~/.config/AutoRaise/config file to disable auto raise:

delay=0

Then:

brew tap fredngo/autoraise-experimental
brew install --HEAD fredngo/autoraise-experimental/autoraise
brew services start autoraise

[sbmpost]

@git-rz
Thanks for these numbers.
I see similar results on my machine. Not sure about older ones though. And good that it works of course :)

[sbmpost]

@Laaarge @samholmes @dreeves @git-rz @fredngo @BenJackGill
With this much iterations, I thought it was a good idea to merge all of this to master after all. To make it clear this is an experimental feature, and that it can break anytime Apple decides to change their private SkyLight API, I made it a compile time option called EXPERIMENTAL_FOCUS_FIRST (see also the updated README).

Thanks to all of you for providing me with most valueable feedback!!

[git-rz]

Working great so far:

[fredngo]

This is awesome, guys.

I've updated my homebrew formula to compile with the EXPERIMENTAL_FOCUS_FIRST flag, so you can:

brew tap fredngo/autoraise-experimental
brew install --HEAD fredngo/autoraise-experimental/autoraise
brew services start autoraise

and it'll automatically compile the binary with that flag. I'm still using the experimental branch in the homebrew formula, but at some point can switch it to master if the branch goes away.

My ~/.config/AutoRaise/config file has the following:

delay=0
mouseStop=true

In preliminary usage it seems to work very well for me!

• I have focus but no raise
• I can select the menu bar even if traversing across multiple other windows
• Launchpad doesn't disappear anymore

Amazing work @sbmpost and everyone on this thread!

[dreeves]

Yeah, I'm pretty blown away by @sbmpost's work on this. And a wonderful community forming here! Thanks, y'all!

Getting it all into master is really nice too. I don't know if it's realistic to have immediate-focus aka focus-first be a setting rather than a compiler flag or even just How It Works. In theory I don't think delayed focus ever makes sense (only delayed autoraise) but obviously I don't understand the ways Apple is making that fraught or fragile. I'm really grateful to have it working exactly how I want now, to the point of avoiding updating macOS like the plague in case Apple breaks this.

Naive idea: instead of a compiler flag, what if it's a compile-time check that enables focus-first if you're on any of an enumerated list of known-compatible versions of macOS?

[fredngo]

Ya personally I'd definitely prefer EXPERIMENTAL_FOCUS to be a config flag instead of a compile-time flag so I can put something like experimentalFocus=true in the config file. Then, I wouldn't need my homebrew formula anymore. But that's up to @smbpost!

[sbmpost]

Thanks for all your nice comments and happy that it works well for all of you. @dreeves: indeed it almost feels like a community ;-)

About the option vs compile time flag: we might want to change that in the future, but I wanted to get this to master quickly as my time is now more limited. A compile time flag is also slightly more efficient in terms of performance. But this is not a deal breaker to make it an option at some point. For now let's hope this version can withstand the future for a while. Most likely I will close this issue sometime next week if nothing else pops up.

Thanks everyone once more! 😃

[fredngo]

@smbpost Thanks to you, MacOS windowing now basically works the way my brain wants it to work; I'm sure some adjustments are always possible but in these few days of preliminary use it seems real good!

Thanks also for considering the config-vs-compile time flag issue.

Thank you again!!!!!

[sbmpost]

@fredngo @Laaarge @samholmes @dreeves @git-rz @BenJackGill
I actually had to push a v3.1 to master because I noticed some small (barely noticeable) regressions.

[fredngo]

I actually had to push a v3.1 to master because I noticed some small (barely noticeable) regressions.

I use bartender also so I guess I better upgrade to that... I've updated my homebrew formula to use master now. I guess I'll have to open a pull request to the original homebrew formula maintainer at this point and get rid of my fork.

[fredngo]

FYI I've added the relevant commits to the original homebrew formula; whenever the pull request is done, my fork of the homebrew formula will become obsolete

[samholmes]

I built AutoRaise from source. Now there's a build on homebrew? What are the exact steps for reference to use the new feature with all the fixes?

[fredngo]

I built AutoRaise from source. Now there's a build on homebrew? What are the exact steps for reference to use the new feature with all the fixes?

Well, the pull request hasn't been accepted into the original homebrew formula yet, but you can check out the documentation on my fork

[samholmes]

@fredngo I get an error trying to install from homebrew:

❯ brew install autoraise --with-dexperimental_focus_first
...
Error: invalid option: --with-dexperimental_focus_first

[samholmes]

❯ brew info autoraise
dimentium/autoraise/autoraise: stable 2.9, HEAD
Focus-follows-mouse for MacOS
https://github.com/sbmpost/AutoRaise
Not installed
From: https://github.com/dimentium/homebrew-autoraise/blob/HEAD/autoraise.rb
License: GPL-3.0
==> Options
--with-dalternative_task_switcher
	CXXFLAGS=-DALTERNATIVE_TASK_SWITCHER
--HEAD
	Install HEAD version
==> Caveats
To restart dimentium/autoraise/autoraise after an upgrade:
  brew services restart dimentium/autoraise/autoraise
Or, if you don't want/need a background service you can just run:
  AutoRaise

Opening https://github.com/dimentium/homebrew-autoraise/blob/HEAD/autoraise.rb#L9 and you see there is only one option available,

[fredngo]

I built AutoRaise from source. Now there's a build on homebrew? What are the exact steps for reference to use the new feature with all the fixes?

Well, the pull request hasn't been accepted into the original homebrew formula yet, but you can check out the documentation on my fork

@samholmes: As I said, my pull request is still pending

[git-rz]

@sbmpost, I am seeing another issue, however I'm not sure if AutoRaise or iTerm2 is the best place for the fix.

I am using focus-follows-mouse support within iTerm2. I expect the pane underneath the mouse pointer to focus when the mouse moves to the pane.

The issue is that when using Autoraise in Focus-only mode, and when the pointer returns to a non-active pane of iTerm2 from a window of a different application, then the pane does not get the focus.

The pane only gets focus when the pointer moves across a pane boundary within iTerm2.

To reproduce: split iTerm2 into two panes, top and bottom. Snap the iTerm window to the right half of the screen. Snap a browser to the left half. Position the mouse over top half of iterm. Mouse left over the browser. Then reenter iterm on the bottom half.

Observe that the top half of iTerm is still activated.

[fredngo]

Looks like my pull request to https://github.com/Dimentium/homebrew-autoraise has been accepted, so you can all install the experimental flag using that homebrew formula now! @samholmes

[sbmpost]

@git-rz

The issue is that when using Autoraise in Focus-only mode, and when the pointer returns to a non-active pane of iTerm2 from a window of a different application, then the pane does not get the focus.

It looks more like an iTerm bug actually. Try the following to see what I mean:

1. Disable AutoRaise (stop it)
2. Split your iTerm and arrange a browser on the left
3. Focus your iTerm by clicking in the top pane
4. Move the mouse out of iTerm towards the browser
5. Click the browser to give it the focus
6. Move the mouse to the bottom iTerm pane
7. Focus iTerm with the OSX task switcher (using cmd-tab)
8. Move the mouse around in the bottom iTerm pane

After steps 7 and 8, I would expect the bottom iTerm pane to be focused, but it doesn't happen. Not only should iTerm check if the correct pane is focused when the mouse clicks it, but also if it gets the focus through other means (the task switcher or a raise action).

[git-rz]

@smbpost, indeed, I suspected the same.

However, in the steps to reproduce, given that only keyboard navigation is involved, in that case I would argue iTerm should NOT refocus the pane.

Consider the following:

• iTerm window, full screen, split pane.
• Browser window, full screen.
• User editing notes in iTerm.
• User cmd-tab to browser, mouse moves within browser such that another pane would be activated if iTerm were on top
• User cmd-tab back to iTerm to update notes.

In this case, the user would again be annoyed that the focus moved. Even though the mouse is over the pane, the user didn't actually move the mouse within iTerm, so it should not be considered. I will report the behavior to iTerm, but will need to formulate in a way that may actually get implemented.

Unless perfect interoperability with an experimental build of AutoRaise is something the devs over there would consider, I would need to come up with another set of steps that can recreate the issue.

Edit:
... Actually.. step 8 above might be enough to make the case. Only one way to find out..

[sbmpost]

@Laaarge @dreeves @fredngo @samholmes @BenJackGill @git-rz

So far it seems all is well with release 3.1. It has been quite a ride to solve this issue. I am closing it now, thank you all for reporting and additional feedback.

[samholmes]

I’d love it if I can click to raise without it interacting with the window on initial click. But, that’s just me being spoiled at this point.

…

On Mon, May 2, 2022 at 11:22 AM Fred Ngo ***@***.***> wrote: - delay = 0: no autoraise, only focus-follows-mouse (which is instant) Oops, just saw this -- I guess I'm in the delay = 0 club instead then. — Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD6KXIIM6OAZEVL7Y6Q3V3VIAMPFANCNFSM5AOLAK3A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[swissbuechi]

Can someone confirm this experimental feature is still working on Ventura 13.1?
For me it seems like compiling with make CXXFLAGS="-DEXPERIMENTAL_FOCUS_FIRST" && make install and adding delay=0 to my ~/.config/AutoRaise/config is having no effect on the auto focus.
When i set delay=1, the auto focus + auto rise work just fine.

Thanks for any feedback.

[ericslaw]

I would say that this works quite well on macOS 13.1 Ventura
I'm on a MBP with M1 silicon.
I've been desperately wanting this feature since 2015!

Focus clearly moves to chrome on mouse-enter, and the keyboard focus is usually returned to the last element keyboard focus was on (usually the location bar or input field) for the window I'm hovering over. (nice!)

There are some small quirks

• -focusDelay {non-zero} seems required to trigger keyboard focus across chrome windows and to prevent endless looping on chrome windows that did not recently have keyboard focus. Setting to very large numbers gets me closer to true focus-follows-mouse.
• iterm2 prefs > pointer > focus-follows-mouse seems to interfere with AutoRaise, causing iterm2 windows to raise when that is exactly what I dont want. Disabling this and letting AutoRaise focus handle it works much better.
• warping occurred only a few times once during my testing (I could tell from the cursor jump and the scaling effect), but didn't always trigger. I ended up disabling anyway.
• I had some kind of temporal edge case where moving from iterm2 to slack didn't focus on slack, but when I transition from chrome to slack it worked. Clicking windows to change layering order or moving them seemed to make it work again and I cannot recreate.

How I tested:

git clone https://github.com/sbmpost/AutoRaise.git
cd AutoRaise/
make clean
make CXXFLAGS="-DOLD_ACTIVATION_METHOD -DEXPERIMENTAL_FOCUS_FIRST"
./AutoRaise -pollMillis 50 -delay 10000 -focusDelay 1 -warpX 0.25 -warpY 0.1 -scale 5 -altTaskSwitcher true -ignoreSpaceChanged false  -mouseDelta 0.1 -verbose true

I ended up disabling focus-follows-mouse in iterm2 prefs and installed the AutoRaise.app which references ~/.AutoRaise containing

focusDelay=1
delay=999999

[sbmpost]

@ericslaw
Thanks for this writeup :-)

I noticed you use a very large value for delay which effectively disables it. You can achieve the same thing with:

-focusDelay 1 -delay 0

The warp feature might not always work consistently if the alternative task switcher is enabled. It depends a bit on how you do the actual task switching. Using only cmd-tab without alternative task switcher works reliably.

[ericslaw]

My initial experiments using -delay 0 shows functionality was inconsistent. I have now set it to 0 and it is working as designed. I attribute this to the iTerm2 focus-follows-mouse interfering with AutoRaise
and have since disabled that feature of iTerm2.

[paulmil1]

@sbmpost
can the EXPERIMENTAL_FOCUS_FIRST finally become a config flag? i'd like to test some configurations to see which works best for me, but its impossible without messy recompiling

[sbmpost]

@paulmil1
Sorry but this is probably never going to be a config flag because it relies on a private Apple API which can change and break this functionality. This feature therefore isn't "officially" supported and will have to remain experimental until Apple provides a way to focus only instead of raising

[sbmpost]

@paulmil1
Btw to test out these configurations, compiling just once should do right? After that the other settings don't require recompilation. Also the GUI version (provided as a dmg, see the README) allows you to quickly change those settings. The GUI version was compiled with EXPERIMENTAL_FOCUS_FIRST enabled.