sbmpost / AutoRaise

AutoRaise (and focus) a window when hovering over it with the mouse
GNU General Public License v3.0
1.42k stars 60 forks source link

Sonoma: can't get to menu bar without control key #169

Closed tkunze closed 10 months ago

tkunze commented 10 months ago

In Sonoma, I can no longer move my mouse from a (non-maximized) window to the menu bar because as soon as I mouse over the root Finder or any other window, that window becomes the focus and thus, when I get to the menu bar, it is the Finder (or some other applications') menu bar. I have to hold Control to get to the menu.

This seems to be new in Sonoma.

Am I doing something wrong? Config is:

delay=0
focusDelay=1
warpX=0.5
warpY=0.5
scale=1.0
mouseStop=true

(Looks like mouseStop is no longer an option?)

sbmpost commented 10 months ago

@tkunze

Yes I think you are doing something wrong because focus first (without raise) still works in Sonoma. I suggest you make sure no previous instances of AutoRaise are running using "Activity Monitor" and run the GUI version instead. The mouseStop setting is superseded by the focusDelay setting. Anything higher than 1 will require the mouse to stop for a short moment.

tkunze commented 10 months ago

Not sure I made the issue clear, so here is a movie. I am in Music.app. Note the menu says "Music". Then I mouse to the menu to make a selection but now, because I move over the root (desktop) window, the menu switches to "Finder".

In the previous version, this was not a problem. Again, this is with -delay 0 -focusDelay 1.

https://github.com/sbmpost/AutoRaise/assets/239703/d6b77786-d6dd-4ca1-8989-dfaf510011fc

sbmpost commented 10 months ago

Will have a look at this as well ;-) thanks for reporting and the movie

tkunze commented 10 months ago

Could it be that this is the direct result of moving from mouseStop to focusDelay? After all, moving from Music.app over the desktop to the menu bar should focus the Finder (by focusing its root window, the Desktop), correct? So if that is true, then it might still be best to reintroduce something like a mouseStop so users can still reach the menu, which, in non-fullscreen situations, can only be reached by crossing some other application window.

That makes me think that maybe AutoRaise could have two new options, cruise and action:

Specifying cruise could disregard delay and focusDelay. I.e., the syntax could be:

autoraise -delay <num> -focusDelay <num> [other options]
autoraise -cruise <num> -action {raise | focus} [other options]

That way, auroraise would be fully backwards compatible.

Example: autoraise -cruise 3 -action focus = focus below a very slow mouse speed (do not raise).