@Harley Acheson (harley) Is there a particular reason for having the hover timeout set to 100ms? I reduced it and the feature still works, so it feels kind of arbitrarily chosen.

With the timeout of 100ms, I sometimes tried using a shortcut before the focus switch happened, so the shortcut got swallowed because the window wasn't focused yet.
Main use case for me: posing an armature from two camera perspectives, on separate monitors, using either the shortcut "R" or "R R". I use a mouse, so there's a frequent, fast switch between the active windows.

This doesn't get completely avoided when I tried using lower values, but does improve the responsiveness a lot already.

@RedMser (RedMser) - Is there a particular reason for having the hover timeout set to 100ms? I reduced it and the feature still works, so it feels kind of arbitrarily chosen.

It was arbitrarily chosen and I'd love for you to experiment with lower values.

On my machine having it set to 0,1, or 100 gave about the same result with a pause between focus change that seemed about 200ms? But making it a little longer did make the pause longer. So 150 gave me a pause like 250ms.

So I left it at the lowest value that made any difference to me. But that means it could be lowered to help you without it affecting me negatively. So please play around with that value until you find something that feels right and post your results, comments, thoughts here.

Keep in the mind that there might have to be some compromise. If the new window is given INSTANT focus then it might be crappy as you moved your mouse over one window to get to another. So best to test with at least three floating windows. That way you can make sure it works well to auto-focus any window but also feels right to move from A over B to get to C. And if you end up with a range that seems similar, pick the longest as that will involve less window message creation.

This doesn't get completely avoided when I tried using lower values, but does improve the responsiveness a lot already.

Yes, I cannot find any downsides so far. But keep a lookout for that. If we can think of any reason why someone might prefer it off then we have to consider a user option. But I'd rather avoid that if possible. And if we had to have both an option to turn it on and a user-set value for the timeout then I'd probably bail on the idea entirely. So some sweet spot we all like is best.

For non-overlapping windows this seems great, for example for two windows on separate monitors seems like a no-brainer.

There's a few cases where windows are intentionally overlapping and this could cause issues:

• File browser and preferences: window always remains on top, but does go out of focus which is not terrible but also no reason to do it I think.
• Render window: goes below main window when moving to outside. This seems like something that could get annoying, hard to predict but I can imagine a fair amount of users do not keep their mouse inside the window that they are working in.
• Floating window for a single editor like an outliner. Not really something we recommend with Blender's non overlapping workflow, and would actually need auto focus for this to become good, but still stay above the main window.

To me it seems this should be restricted to certain windows, though the exact criteria and possibilities in the Windows API are not clear to me.

The Render window behavior is quite bothersome actually. Having it disappear when I mouse out of it is quite annoying and this happens a lot; both intentionally and accidentally.
The render window is not full-screen in my setup so it falls into that "intentionally overlapping" case. Moving the mouse from Render to an open web browser window? Render disappears unless you make the move in one quick motion. Moving the mouse from Render to another portion of blender? Render disappears.

FWIW my #1 annoyance with the current UI interaction model, that forces me to repeat UI actions and slow down, is from the fact that menus, popups, and context menus auto-close when I mouse out of them. I'd rather not have this behavior now impact entire windows, effectively speaking.

@Jesse Yurkovich (deadpin) - The Render window behavior is quite bothersome actually...

Yes, this is why I preferred the Render window to be "on-top" like other windows, but that was not well-received, probably because its so large.

However, we can just apply this patch to windows that have parents, that way the Render window would behave exactly as it does now, while the other windows would gain this auto-focus functionality. In theory anyway. Will have to take a look at Brecht's notes and makes sure we are all understanding each other.

This latest version of the patch still behaves unexpectedly to me:

• Moving the mouse outside a floating render window does not change the order of windows or appearance of the title bar. Shortcut keys (e.g. J key for slots) do not work with the mouse outside the window anymore.
• Similarly for the file browser dialog shortcuts also do not work outside the window. Unlike the render window the file browser title bar becomes grayed out when the mouse moves outside.

I'm guessing based on this behavior that main and render windows are parents, and the file browser window is a child. If so, I don't see parent/child as the right distinction to make.

I don't know what's possible with the Window API, but the following is what I would expect. Automatic focus gain when moving to another window that is either:

• Not overlapping the current focused window (either above or below), in terms of window bounds. For example a window on another monitor or two windows side by side on the same monitor. This should not raise the window, merely focus it.
• Overlapping and above the current focused window. For example if there is a render window floating above the window on the second monitor, you'd want to be able to move from the first monitor to the second monitor main window and then continue to the floating render window. At no point should the order of windows change.