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

Harley Acheson · 2023-03-05T00:15:00+01:00

Harley Acheson commented

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

Don't allow the hover of mouse to auto-raise another window while you
are entering data into a text or number input.

On the Windows platform, commit #104681 allows the hovering of the mouse to auto-raise and -focus child windows. This allows the use of keyboard shortcuts to work on the window without needing to activate it with a mouse click. However, @kursadk reported that this can be inconvenient when entering a filename in the File Browser if your mouse is not in, or leaves, that window.

This PR has ui_textedit_begin and ui_textedit_end call a new GHOST_SetAutoFocus to pause this feature while entering text. Seems to work great.

It has recently become more important to not revert #104681. 24f3cb9b5c had to remove the passing along of keyboard modifiers when mouse activating windows (because this interferes with Alt-Tab switching). This means we could once again get complains of #40059. #104681 should minimize that.

Don't allow the hover of mouse to auto-raise another window while you are entering data into a text or number input. --- On the Windows platform, commit #104681 allows the hovering of the mouse to auto-raise and -focus child windows. This allows the use of keyboard shortcuts to work on the window without needing to activate it with a mouse click. However, @kursadk [reported](https://projects.blender.org/blender/blender/pulls/104681#issuecomment-894869) that this can be inconvenient when entering a filename in the File Browser if your mouse is not in, or leaves, that window. This PR has `ui_textedit_begin` and `ui_textedit_end` call a new `GHOST_SetAutoFocus` to pause this feature while entering text. Seems to work great. It has recently become more important to not revert #104681. 24f3cb9b5c1b089b56a9601e175ac9d33a86dda0 had to remove the passing along of keyboard modifiers when mouse activating windows (because this interferes with Alt-Tab switching). This means we could once again get complains of #40059. #104681 should minimize that.

❤️ 1

Harley Acheson added 1 commit 2023-03-05 00:15:12 +01:00

43d0bd87b6 Win32: Pause Window Auto-Focus During Text Entry

Don't allow the hover of mouse to auto-raise another window while you
are entering data into a text or number input.

Jesse Yurkovich referenced this pull request

2023-03-05 00:26:25 +01:00

Open/Save window should not allow shortcuts for unwanted changes #105435

Harley Acheson added 1 commit 2023-03-05 00:38:32 +01:00

buildbot/vexp-code-patch-coordinator Build done. Details

5f1376deb3 Merge branch 'main' into SelectableFocus

Harley Acheson commented

2023-03-05 00:40:56 +01:00

@blender-bot package windows

Blender Bot commented

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

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR105446) when ready.

Harley Acheson referenced this pull request

2023-03-05 02:19:54 +01:00

Open/Save window should not allow shortcuts for unwanted changes #105435

Harley Acheson changed title from ~~Win32: Pause Window Auto-Focus During Text Entry~~ to Fix #105435: Pause Win32 Auto-Focus During Text Entry

2023-03-05 02:20:28 +01:00

Harley Acheson requested review from Brecht Van Lommel 2023-03-06 00:46:04 +01:00

Harley Acheson added 1 commit 2023-03-07 22:56:09 +01:00

buildbot/vexp-code-patch-coordinator Build done. Details

c3b5c0a19b Merge branch 'main' into SelectableFocus

Harley Acheson commented

2023-03-07 23:02:29 +01:00

@blender-bot package windows

Blender Bot commented

2023-03-07 23:02:33 +01:00

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR105446) when ready.

Brecht Van Lommel commented

2023-03-08 18:13:55 +01:00

This seems good to me, even if we ever decide to make the file window modal it's still good to not change focus when typing text.

Have you tested what the behavior is when cursor grabbing is enabled? Like transforming with G key or dragging a number slider, with the mouse ending up over another window. I think we definitely should not be changing window focus during such an operation. But I'm not sure if it's already prevented.

This seems good to me, even if we ever decide to make the file window modal it's still good to not change focus when typing text. Have you tested what the behavior is when cursor grabbing is enabled? Like transforming with G key or dragging a number slider, with the mouse ending up over another window. I think we definitely should not be changing window focus during such an operation. But I'm not sure if it's already prevented.

Harley Acheson commented

2023-03-08 19:24:14 +01:00

Have you tested what the behavior is when cursor grabbing is enabled? Like transforming with G key or dragging a number slider, with the mouse ending up over another window. I think we definitely should not be changing window focus during such an operation. But I'm not sure if it's already prevented.

Yes, have not found anything else with current code that behaves badly.

With the cursor grabbing stuff, dragging an object or dragging within a numerical input, never actually leaves the window (as far as the OS is concerned) so we never get a message to other windows.

Modal operations that can leave the window also don't activate other windows either. So doing an area join but pull out to some other Blender window it does not activate. Probably because of mouse capture.

Dragging operations between windows also don't activate the target window (the source remains active), although it could and would be fine. My fix for dragging from Outliner to other windows works fine. #105196

Operations that don't involve a mouse being held are also fine. Like doing an eyedropper pick between Blender windows. Moving over various Blender windows does not activate them. It is only that final "click" to sample a color that will make the window active.

> Have you tested what the behavior is when cursor grabbing is enabled? Like transforming with G key or dragging a number slider, with the mouse ending up over another window. I think we definitely should not be changing window focus during such an operation. But I'm not sure if it's already prevented. Yes, have not found anything else with current code that behaves badly. With the cursor grabbing stuff, dragging an object or dragging within a numerical input, never actually leaves the window (as far as the OS is concerned) so we never get a message to other windows. Modal operations that can leave the window also don't activate other windows either. So doing an area join but pull out to some other Blender window it does not activate. Probably because of mouse capture. Dragging operations between windows also don't activate the target window (the source remains active), although it could and would be fine. My fix for dragging from Outliner to other windows works fine. #105196 Operations that don't involve a mouse being held are also fine. Like doing an eyedropper pick between Blender windows. Moving over various Blender windows does not activate them. It is only that final "click" to sample a color that will make the window active.

Brecht Van Lommel approved these changes 2023-03-08 20:05:31 +01:00

Brecht Van Lommel left a comment

Thanks for the explanation, this looks good then.

Harley Acheson added 1 commit 2023-03-08 21:43:56 +01:00