There were two problems dropping files into blender:
- The inputs `focus_pointer` was NULL, causing a crash.
- The wl_data_device_manager version was set to 1, causing the Blender
window to close (when dropping files in gnome-shell 42).
Resolve by storing the drop surface separately from the pointer surface
and bump the device manager version to 3.
Many errors involving mis-use or unexpected situations report an
error and close Blender's window buy don't crash, making it difficult
to track down when the error occurs.
Define an error handler prints the error and a back-trace,
it can also be useful for setting a break-point
The software cursor was being enabled with absolute events,
causing a problem with absolute tablet events.
This caused both cursors to be visible at once when using a tablet
(with D15152 applied).
As Wayland doesn't support moving the cursor, draw a cross-hair cursor
at the location used by Blender.
Without this, the cursor was locked at the location where grab started,
making some actions unusable since the cursor location was invisible.
Resolves T77311.
Grab which didn't wrap would lock the cursor, making actions such
as resizing areas lock the cursor in-place.
Confine the cursor to the window instead.
This behavior was also used for X11 when grabbing the cursor was first
supported but could lock the system if Blender froze while grabbing so
it was disabled [0].
For Wayland this shouldn't be a problem as compositors implement grab
in a way that prevents the client from locking the system.
[0]: 3e3d2b7a4c
Shifted flag for buttons changed was incorrectly compared with
unshifted packet flag to determine button press state.
Also fix button tracking storage; button flags are 32 bits whereas the
member variable was 8.
Differential Revision: https://developer.blender.org/D14915
Since [0], using the view navigation gizmo crashed with Wayland.
This only worked previously because GHOST_kGrabWrap was ignored.
Now the previous grab state is disabled before switching to a new
grab state.
[0]: da9e14b0b9
Dragging number buttons wasn't grabbing the cursor and would stop
when the pointer reached the screen edge & wasn't setting the cursor
visible on completion.
Check that lParam is non-NULL in WM_SETTINGCHANGE message handler.
See D14867 for details.
Differential Revision: https://developer.blender.org/D14867
Reviewed by Jesse Yurkovich
Blender will respect Windows "Dark Mode" setting for title bar color.
See D14847 for details.
Differential Revision: https://developer.blender.org/D14847
Reviewed by Ray Molenkamp
When creating a new window from a duplicated area - by shift-dragging
on corner action zones - on the Windows platform the resulting window
is initially unresponsive. This patch fixes this by releasing the parent
window's mouse capture.
See D14085 for more details.
Differential Revision: https://developer.blender.org/D14085
Reviewed by Ray Molenkamp
Windows IME: Fix duplicated initial character when entering numbers
while in Chinese full width character mode.
See D14354 for more details.
Differential Revision: https://developer.blender.org/D14354
Reviewed by Brecht Van Lommel
Mousemove events are sent to windows.
In Windows OS, almost all mousemove events are sent to the window whose
mouse cursor is over.
On MacOS, the window with mousemove events is always the active window.
It doesn't matter if the mouse cursor is inside or outside the window.
So, in order for non-active windows to also have events,
`WM_window_find_under_cursor` is called to find those windows and send
the same events.
The problem is that to find the window, `WM_window_find_under_cursor`
only has the mouse coordinates available, it doesn't differentiate
which monitor these coordinates came from.
So the mouse on one monitor may incorrectly send events to a window on
another monitor.
The solution used is to use a native API on Mac to detect the window
under the cursor.
For Windows and Linux nothing has changed.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D14197
This fixes T93051, T76405 and maybe others.
Characters like '²', '<' are not recognized in Blender's shortcut keys.
And sometimes simple buttons like {key .} and {key /} on the Windows
keyboard, although the symbol is "known", Blender also doesn't
detect for shortcuts.
For Windows, some of the symbols represented by `VK_OEM_[1-8]` values,
depending on the language, are not mapped by Blender.
On Mac there is a fallback reading the "actual character value of the
'remappable' keys". But sometimes the character is not mapped either.
On Windows, the solution now mimics the Mac and tries to read the button's
character as a fallback.
For unmapped characters ('²', '<', '\''), now another value is chosen as a
substitute.
More "substitutes" may be added over time.
Differential Revision: https://developer.blender.org/D14149
Helps with building against different OpenXR SDK versions (i.e. for
downstream builds that require specific versions), as the extension was
only defined since OpenXR 1.0.22.
