The same solution used in rBb94ab93dfb82: Eyedropper: Support get samples from other windows solves the problem.
The idea of that solution is to find the window and region under the cursor to use in the operator.
Details
Details
Diff Detail
Diff Detail
- Repository
- rB Blender
- Branch
- master
- Build Status
Buildable 16601 Build 16601: arc lint + arc unit
Event Timeline
Comment Actions
- Fix continuous mouse move on Mac
In this case the window needs to be set (according to other OS).
Comment Actions
But something has changed in GHOST since then, and the events of the window where the operator was called (which includes the eyedropper's modal operator) are not captured if the mouse cursor is over another window.
Before we go into the rather complicated solution in this patch, have you identified what changed? Wouldn't we have the same problem for e.g. transform operators without continuous grab?
Comment Actions
EDIT: I didn't notice that continuous grab is disabled with the option --debug
Continuous grab calls the updateMouseCapture(OperatorGrab) function which does exactly what this patch proposes to expose.
Comment Actions
I was referring to the case where continuous grab is disabled in the preferences, then it's similar to what we want for color picking. Grabbing the cursor but not warping or hiding it.
Maybe that can be improved, rather than adding an additional force capture state.
Comment Actions
- Remove GHOST changes
Operators with the OPTYPE_BLOCKING option always called WM_cursor_grab_enable(CTX_wm_window(C), wrap, false, bounds) which did exactly what this path proposed: Force events to a single window.
I hadn't noticed this before because I had the --debug option enabled which internally disables the continuous grab activation (why does it even do this????)
(This weird behavior of --debug made me waste a lot of time -_-)
Comment Actions
That --debug behavior is indeed quite odd. It's apparently due to issues using a debugger with cursor grabbing (rBdcecd8e), not sure how relevant that still is.