Mouse button numbers are passed through directly, and axis values are passed through as the raw, 32-bit, wl_fixed_t 24.8 fixed-point values, which need to be divided by the denominator to convert to int/float.
This commit does the following:
- add logic in the `WM_MOUSEMOVE` case of the Window to conditionally call `WIN_UpdateClipCursor` upon receiving cursor motion if SDL is expecting the mouse to be clipped in some way (Fixes#7890)
- remove Windows-specific periodic refresh of cursor clipping and its `SDL_HINT_MOUSE_RELATIVE_CLIP_INTERVAL` hint (superceded by the above bullet point)
- streamline the processing logic within `WIN_UpdateClipCursor` for better readability of each branch, and avoid calling the Platform API until it is absolutely necessary.
- move `relative_mouse_center` field from Windows-specific per-window `SDL_WindowData` to the global `SDL_Mouse` struct, and the corresponding hint callbacks to `SDL_mouse.c` instead of `SDL_windowswindow.c`
When using `SDL_ConvertEventToRenderCoordinates` with
`SDL_EVENT_FINGER_MOTION` events it converts `x` and `y` coordinates but
does not convert the the `dx` and the `dy` unlike `xrel` and `yrel` of
mouse motion events. This is means that these are rather useless after
conversion. This change unifies this behavior between touch and mouse
motion events.
Slave pointer devices can seemingly lag behind the master for some reason, so use the master pointer coordinates for absolute motion.
Master events are now only filtered out on the pen path.
- Removes SDL_RenderDebugTextV
- Changes SDL_RenderDebugTextF to SDL_RenderDebugTextFormat and tweaks it to
work in a world without SDL_RenderDebugTextV.
- Tweaked rendering position of formatted text in the example program.
The Windows implementation of dialogs use the Win32 API, which expects the file filters to have null bytes as separator, and two null bytes at the end of the filter list. To help with string manipulation, the internal code uses 0x01 bytes instead of null bytes, and converts all 0x01 bytes into null bytes at the last moment. If someone decides to put two consecutive 0x01 bytes in their filter names, the code might mistakenly pick them up and convert them to null bytes, leading to Windows failing to pick up later filters. In practice, this is probably not so bad, since it requires someone to have control over file filters already, and allows at most ignoring the following file filters. It is also unlikely to happen by accident since 0x01 is not printable. This commit fixes that by replacing all the 0x01 bytes with the space character.
For some obscure reason I can't remember, I had made it so the suffix would be added only if the filter list was empty. That isn't the expected behavior and caused a mishandling of memory on Windows, which requires a two-null-bytes suffix.
It is not uncommon for clients to redundantly set the window size and position, either as a holdover from an SDL 1 port, when this was required, due to any window state change triggering a universal update function that sets all window state, even if unnecessary (e.g. always calling SDL_SetWindowSize(), even if the window is fullscreen), or due to the use of compatability layers. Historically, these clients expect that their behavior won't override the base window state, which is an assumption that the windowing changes in SDL 3 broke by caching size and position changes that can't be applied immediately.
This change drops size and position requests when the window is in the maximized and fullscreen states (fullscreen-desktop windows will be repositioned, but the non-fullscreen floating position will not be overwritten), which is behavior more in line with existing client assumptions, and should ease the porting process, as well as prevent annoying bugs when older software is run via sdl2-compat.
In the process of making these changes, pending window state has been moved to separate variables in the SDL_Window struct, as this fixes bugs regarding fullscreen display selection and centering windows immediately after resize on asynchronous platforms, which had issues due to pending state possibly being overwritten.
It's possible (likely!) someone could just pass a pointer returned by
SDL_GetError for one of these strings, but the message box code has to do a
ton of complicated stuff that might _also_ call SDL_SetError, so you could
end up with the string having different contents by the time you display it.
Just make a copy of the strings unconditionally at the start, so they're safe
no matter where they came from.
Fixes#10932.
