When you have multiple monitors you inevitably have to deal with multiple blender windows. On the Windows platform it is by (Microsoft) design that only one window can have focus (receive mouse and keyboard input) at a time. You enable a window to get focus by clicking on it. However this can be inconvenient, especially when it isn’t that obvious which one is active.
I’m hoping that Windows users can test the following build: Blender 3.5.0 D13951
It makes most Blender child windows auto-focus when your mouse moves into the client area:
Some things to keep in mind:
This does NOT affect any interaction between Blender windows and other applications. It is only between windows of a single Blender instance.
Auto-focusing only occurs when hovering over the client portion of the window, not non-client areas like the caption (title bar).
Auto-focusing happens in these specific situations:
Moving your mouse from a child window to its parent
Moving from parent to child
Between siblings of the same parent
Between main parent windows that do not overlap
Auto-focusing does not occur:
Between main parent windows that overlap each other
Between child windows of different parents
Between any windows of separate applications or Blender instances.
Most importantly I am currently proposing that this be a non-optional part of Blender, so enabled at all times for all Windows users. I have not found any downsides to this, so am on the lookout for anything that proves me wrong: situations where this hinders rather than helps.
Please don’t comment here if you have not actually tried the build (or have compiled the patch yourself). Guesses about how it feels are not very helpful.
But give it a go and try to find situations where having it work this way is worse than not.
Hi, tested both patch and build, it works well for me
As of now auto-focus between two and more New main windows of same blender instance is not working. Is this expected?
Yes, there will always be a delay between moving your mouse and having it become active. I have the very minimum possible value set for this but I generally see a delay of about 200ms. So this is probably a system limitation, possibly purposeful.
If the change were instantaneous there would be times that it would be annoying anyway. When moving your mouse from one window to another while crossing over one in the middle.
My general concerns about this patch is that during evaluation most people are going to be noticing the times that it works as expected and will love that. Yeah!, something is working now that didn’t work before.
However, once in master we might get complaints about the times when it doesn’t work. “Why does it work in that situation, but doesn’t in this one?” As described in the top description, the rules are fairly complex. So it might not be easy to simply state why it can’t work as expected in all situations.
The rules are complex because of compromises made earlier. It was a few years ago that I finally got us with child windows behaving in a way that works: on top of their parents. This was important because not doing so you can click anywhere on a parent and the child will dive underneath. But once committed we got a few complaints about the “Render” window. We’ve always made that one too large, and people got used to using a particular key combination to switch between it and the main window. So in the end I had to make that one window a “parent” window instead. So it cannot participate in this auto-raise (otherwise hovering over any part of the main window will push the Render window below). So another “make it better but don’t make changes” that hamstrings me from further improvements.
So right now the big questions aren’t really about if this feature works well when it does. But does it ever do anything unexpected? And do the times it doesn’t work make sense? Will the “it works here but doesn’t work there” result in complaints?
Was testing this and it seems to be working as expected. There should be auto-focusing between multiple “new main windows”, but only if they don’t overlap.
The reason for that “not overlapping” rule for main (parent) windows is because of the “Render” window, as mentioned earlier in this thread. I had tried to make that window be a child like all the rest but was forced by complaints to make that a parent window. So if auto-focus were to occur between it and the main window you’d get all sorts of weirdness. Because it isn’t “on top” whenever you hovered any part of the main window it would cause Render to dive under.
Good question. You have two windows and you move your mouse over to the one that is not active. The fix you reference means you can shift-mouse drag to pan correctly because not only does that mouse click make the window active, but that initial first shift is detected as well. So windows activation happen transparently.
But now hover over an inactive window and right over a 3D View. Press “g” to move something. That can’t work because the window is inactive and not accepting keyboard input. This patch makes it active within about 200ms of you hovering over it. So keyboard input works between windows transparently.
works fine here! but i have another unnamed 3d software that has a child window/process (named after a green hopping insect, node based) and the transition is instant (but only if a command is active and the viewport is redrawing / waiting for user input).
Not that the delay bothers me, but its seems possible. (can send you a video if that helps)
Yes, this is discussed above. This patch uses a value that is lower than recommended by Microsoft for this use, but seems okay anyway. As mentioned, “If the change were instantaneous there would be times that it would be annoying anyway. When moving your mouse from one window to another while crossing over one in the middle”
Harley thank you so much for trying to push this through and I just wanted to chime in and add my vote/support because I really hope this becomes canon.
