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

Merged
Harley Acheson merged 4 commits from Harley/blender:SelectableFocus into main 2023-03-08 22:20:45 +01:00
Member

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.
Harley Acheson added 1 commit 2023-03-05 00:15:12 +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.
Harley Acheson added 1 commit 2023-03-05 00:38:32 +01:00
Merge branch 'main' into SelectableFocus
Some checks failed
buildbot/vexp-code-patch-coordinator Build done.
5f1376deb3
Author
Member

@blender-bot package windows

@blender-bot package windows
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR105446) when ready.
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
Merge branch 'main' into SelectableFocus
All checks were successful
buildbot/vexp-code-patch-coordinator Build done.
c3b5c0a19b
Author
Member

@blender-bot package windows

@blender-bot package windows
Member

Package build started. Download here when ready.

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

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.
Author
Member

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
Owner

Thanks for the explanation, this looks good then.

Thanks for the explanation, this looks good then.
Harley Acheson added 1 commit 2023-03-08 21:43:56 +01:00
Merge branch 'main' into SelectableFocus
All checks were successful
buildbot/vexp-code-patch-coordinator Build done.
c6707b6fdd
Author
Member

@blender-bot build

@blender-bot build
Harley Acheson merged commit 56d2298271 into main 2023-03-08 22:20:45 +01:00
Harley Acheson deleted branch SelectableFocus 2023-03-08 22:20:45 +01:00
Sign in to join this conversation.
No reviewers
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#105446
No description provided.