Win32: Auto-Raise and -Focus Windows on Hover #104681

Harley Acheson · 2023-02-13T03:28:51+01:00

Harley Acheson commented

2023-02-13 03:28:51 +01:00

On the Windows platform, raise windows and give them focus as the mouse
hovers over them. This allows keyboard shortcuts for the area under the
mouse without having to click the window caption to make them active.

This patch makes it so that as you move your mouse between different Blender windows the window under the mouse automatically becomes active - raises and gets focus. And does so all the time and without any user configuration.

Note that this is only when hovering over the client portion of the window, not non-client areas like the caption (title bar). And this is ONLY between separate windows within a single Blender instance, and NOT between Blender and other applications.

Even between Blender windows, not everything is auto-focused. But most things. Specifically:

Child to parent
Parent to child
Between siblings of the same parent
Between main windows that do not overlap.

The situations where windows are NOT auto-focused are primarily:

main parent windows that overlap each other
between child windows of different parents

On the Windows platform, raise windows and give them focus as the mouse hovers over them. This allows keyboard shortcuts for the area under the mouse without having to click the window caption to make them active. --- This patch makes it so that as you move your mouse between different Blender windows the window under the mouse automatically becomes active - raises and gets focus. And does so all the time and without any user configuration. Note that this is only when hovering over the client portion of the window, not non-client areas like the caption (title bar). And this is ONLY between separate windows within a single Blender instance, and NOT between Blender and other applications. Even between Blender windows, not everything is auto-focused. But most things. Specifically: * Child to parent * Parent to child * Between siblings of the same parent * Between main windows that do not overlap. The situations where windows are NOT auto-focused are primarily: * main parent windows that overlap each other * between child windows of different parents

❤️ 2 🎉 1

Harley Acheson added 1 commit 2023-02-13 03:28:53 +01:00

4d336038ce Win32: Auto-Raise and -Focus Windows on Hover

On the Windows platform, raise windows and give them focus as the mouse
hovers over them. This allows keyboard shortcuts for the area under the
mouse without having to click the window caption to make them active.

Brecht Van Lommel commented

2023-02-13 09:02:22 +01:00

I haven't tested the latest version of the patch on Windows, but I'm doubtful about child to parent focusing.

If I remember correctly preferences and file browser are child windows, while the render window is not. Regardless, I can't think of a case where I would want any of those windows to automatically go behind the parent window.

Personally at least I can imagine letting the cursor rest outside the child window, to get an unobstructed view of the contents of the child window, and then it suddenly disappearing.

Previous discussion for reference:
https://archive.blender.org/developer/D13951

I haven't tested the latest version of the patch on Windows, but I'm doubtful about child to parent focusing. If I remember correctly preferences and file browser are child windows, while the render window is not. Regardless, I can't think of a case where I would want any of those windows to automatically go behind the parent window. Personally at least I can imagine letting the cursor rest outside the child window, to get an unobstructed view of the contents of the child window, and then it suddenly disappearing. Previous discussion for reference: https://archive.blender.org/developer/D13951

Brecht Van Lommel requested changes 2023-02-13 09:05:26 +01:00

Brecht Van Lommel left a comment

Marking as request change due to question.

Brecht Van Lommel added this to the User Interface project 2023-02-13 09:06:29 +01:00

Harley Acheson commented

2023-02-13 18:51:27 +01:00

If I remember correctly preferences and file browser are child windows, while the render window is not. Regardless, I can't think of a case where I would want any of those windows to automatically go behind the parent window.

They don't. On Windows if it is a child then it always remains in front of its parent. So for these focus can change from parent to child and back and nothing changes in z-order.

Render window is not a child. But this patch does not automatically change focus for windows like this that have any overlap. It will do so if they don't overlap, in which case there is no z-order change.

Personally at least I can imagine letting the cursor rest outside the child window, to get an unobstructed view of the contents of the child window, and then it suddenly disappearing.

For sure and for child windows all that would happen is the parent would get focus (so the titlebar would change) but otherwise everything would remain the same.

Previous discussion for reference:
https://archive.blender.org/developer/D13951

You did try it early on and raised similar issues as above that were addressed with the change to having it not change focus on overlapping peer windows.

I subsequently made builds available and asked for feedback here: https://devtalk.blender.org/t/please-test-windows-auto-focus-patch-build/26965

Got a "brings tears to my eyes". LOL

> If I remember correctly preferences and file browser are child windows, while the render window is not. Regardless, I can't think of a case where I would want any of those windows to automatically go behind the parent window. They don't. On Windows if it is a child then it always remains in front of its parent. So for these focus can change from parent to child and back and nothing changes in z-order. Render window is not a child. But this patch does not automatically change focus for windows like this that **have any overlap**. It will do so if they don't overlap, in which case there is no z-order change. > Personally at least I can imagine letting the cursor rest outside the child window, to get an unobstructed view of the contents of the child window, and then it suddenly disappearing. For sure and for child windows all that would happen is the parent would get focus (so the titlebar would change) but otherwise everything would remain the same. > Previous discussion for reference: > https://archive.blender.org/developer/D13951 You did try it early on and raised similar issues as above that were addressed with the change to having it not change focus on overlapping peer windows. I subsequently made builds available and asked for feedback here: https://devtalk.blender.org/t/please-test-windows-auto-focus-patch-build/26965 Got a "brings tears to my eyes". LOL

Brecht Van Lommel approved these changes 2023-02-13 18:55:53 +01:00

Brecht Van Lommel left a comment

Thanks, given the explanation and user feedback this looks good to me.

Harley Acheson referenced this issue from a commit

2023-02-22 19:27:35 +01:00

Win32: Auto-Raise and -Focus Windows on Hover

Harley Acheson commented

2023-02-22 19:40:38 +01:00

Closing with manual commit: defd95afcd

Closing with manual commit: https://projects.blender.org/blender/blender/commit/defd95afcd44a17a82c54134a9762290b384e664

Harley Acheson closed this pull request

2023-02-22 19:40:38 +01:00

Harley Acheson deleted branch AutoFocus

2023-02-22 19:41:22 +01:00

Harley Acheson referenced this pull request

2023-03-03 16:25:13 +01:00

Alt key is always stuck when changing to Blender on Windows with multiple monitors #105381

kursad k commented

2023-03-03 17:49:29 +01:00

While this patch sounds really helpful, it caused a lot of confusion while testing nightlies, I believe this patch is the main reason for it. I used to be able to type file names when saving a file using file save window and not worry about where my mouse pointer was. Now pressing a wrong button can messes up your scene, change frames etc if the mouse pointer is not exactly within the borders of the save window, which happened to me a lot lately.

If this patch is in the main, maybe the file save window should be blocking other windows, because I feel like this is really dangerous and the user might not realize that she is messing up with the scene just prior to saving the file.

While this patch sounds really helpful, it caused a lot of confusion while testing nightlies, I believe this patch is the main reason for it. I used to be able to type file names when saving a file using file save window and not worry about where my mouse pointer was. Now pressing a wrong button can messes up your scene, change frames etc if the mouse pointer is not exactly within the borders of the save window, which happened to me a lot lately. If this patch is in the main, maybe the file save window should be blocking other windows, because I feel like this is really dangerous and the user might not realize that she is messing up with the scene just prior to saving the file.

Harley Acheson commented

2023-03-03 18:14:57 +01:00

I used to be able to type file names when saving a file using file save window and not worry about where my mouse pointer was...

Thanks for this comment, that does sound annoying.

If this patch is in the main, maybe the file save window should be blocking other windows...

I don't think that making the File Browser window blocking could be a possible solution as there are many people who rely on using it non-modally, like opening for one purpose but then dragging an image into the 3DViewport instead.

I'd hate to give up on this change though as it offers such nice utility when working with multiple windows. We get so many reports from people saying it is a pain to have to select a window just to use hotkeys.

Do you mind continuing to evaluate this impact, while considering possible solutions and the tradeoff with not having to activate child windows manually? One possible solution is to just make this feature an opt-in preference, but I'd much rather avoid this if possible.

> I used to be able to type file names when saving a file using file save window and not worry about where my mouse pointer was... Thanks for this comment, that does sound annoying. > If this patch is in the main, maybe the file save window should be blocking other windows... I don't _think_ that making the File Browser window blocking could be a possible solution as there are many people who rely on using it non-modally, like opening for one purpose but then dragging an image into the 3DViewport instead. I'd hate to give up on this change though as it offers such nice utility when working with multiple windows. We get so many reports from people saying it is a pain to have to select a window just to use hotkeys. Do you mind continuing to evaluate this impact, while considering possible solutions and the tradeoff with not having to activate child windows manually? One possible solution is to just make this feature an opt-in preference, but I'd much rather avoid this if possible.

❤️ 1

Brecht Van Lommel commented

2023-03-03 18:28:30 +01:00

If the focus is on a text field or a modal operator is running, it probably should not change the window focus automatically?

Maybe the information is already at the GHOST level through cursor grabbing and IME, not sure if it's enough.

If the focus is on a text field or a modal operator is running, it probably should not change the window focus automatically? Maybe the information is already at the GHOST level through cursor grabbing and IME, not sure if it's enough.

❤️ 1

Harley Acheson commented

2023-03-03 19:21:45 +01:00

If the focus is on a text field or a modal operator is running, it probably should not change the window focus automatically?
Maybe the information is already at the GHOST level through cursor grabbing and IME, not sure if it's enough.

We would have more options if this wasn't just an isolated change to GHOST_SystemWin32.cpp. This could be exposed higher up, so a wmWindow could have some "don't change focus automatically" that could be set/unset at times. Not sure that that would look like, but maybe "allow_hoverfocus" or similar

But... simpler I could use the "is_dialog" argument that is sent during window creation. On Windows we aren't doing anything with it because we generally don't want different look or behavior with our windows, or even (yet) have code that could make them actually modal (disallowing events to the parent for example). But this might be a bit of "is_dialog" that makes sense. AFAIK File Browser is the only window that is created with is_dialog true (it has changed behavior on Mac). I don't think it is misusing the idea since a true modal dialog would not allow hover focus either.

But the first idea feels better.

> If the focus is on a text field or a modal operator is running, it probably should not change the window focus automatically? > Maybe the information is already at the GHOST level through cursor grabbing and IME, not sure if it's enough. We would have more options if this wasn't just an isolated change to GHOST_SystemWin32.cpp. This could be exposed higher up, so a wmWindow could have some "don't change focus automatically" that could be set/unset at times. Not sure that that would look like, but maybe "allow_hoverfocus" or similar But... simpler I _could_ use the "is_dialog" argument that is sent during window creation. On Windows we aren't doing anything with it because we generally don't want different look or behavior with our windows, or even (yet) have code that could make them actually modal (disallowing events to the parent for example). But this might be a bit of "is_dialog" that makes sense. AFAIK File Browser is the only window that is created with is_dialog true (it has changed behavior on Mac). I don't think it is misusing the idea since a true modal dialog would not allow hover focus either. But the first idea feels better.

kursad k commented

2023-03-03 20:33:16 +01:00

Do you mind continuing to evaluate this impact, while considering possible solutions and the tradeoff with not having to activate child windows manually? One possible solution is to just make this feature an opt-in preference, but I'd much rather avoid this if possible.

I think this is a great feature just that it has a some bad side effects when trying to save a file. I actually deleted objects while saving, instead of deleting a character or moved to wrong frames etc.

I will keep testing it. I feel like this could be optional like you mentioned.

> Do you mind continuing to evaluate this impact, while considering possible solutions and the tradeoff with not having to activate child windows manually? One possible solution is to just make this feature an opt-in preference, but I'd much rather avoid this if possible. > > > I think this is a great feature just that it has a some bad side effects when trying to save a file. I actually deleted objects while saving, instead of deleting a character or moved to wrong frames etc. I will keep testing it. I feel like this could be optional like you mentioned.

Harley Acheson referenced this pull request

2023-03-05 00:15:00 +01:00

Fix #105435: Pause Win32 Auto-Focus During Text Entry #105446

Harley Acheson commented

2023-03-08 00:03:26 +01:00

@kursadk - I'm hoping you can test the following build:

https://builder.blender.org/download/patch/PR105446/

@kursadk - I'm hoping you can test the following build: https://builder.blender.org/download/patch/PR105446/

❤️ 1