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.
I am confused by the "You have to manually edit this file" comment. Does it mean that it is expected to manually remove the previous `#define SDL_LEAN_AND_MEAN 0` ?
In any case I put this part of the change in a separate commit so that it can easily be reverted.
Some compositors may not implement commit-timing-v1 in addition to fifo-v1, at least not immediately, and Mesa doesn't require commit-timing for FIFO behavior. The fifo-v1 protocol alone is enough for the desired behavior.
Only check for fifo-v1 to enable Wayland by default.
This used to do different things for recording streams in different parts of
the codebase, not to mention two separate codepaths through
UpdateAudioStreamFormatsPhysical in any case. My hope is this should kill off
a few corner case bugs...for example, this one:
Fixes#8402.
This could happen if you call SDL_BindAudioStreams() when the subsystem isn't
initialized, and possibly in other corner cases.
Thanks to Qianxin CodeSafe Team, @QiAnXinCodeSafe, for discovering this issue!
Fixes#11643.
A property cleanup callback might end up trying to set other properties, so we don't want to have a lock held at that point.
Fixes an assertion in testprocess when cleaning up IO stream properties
Read-write locks are not recursive and can't be upgraded from one type to another, so it's not safe to lock the hash table and then call functions that operate on it. If you really want this functionality, we'd need to create unlocked versions of the hashtable functions and you would call those once you've taken a lock on the hashtable, and we'd have to assert that the operations you're doing are compatible with the type of lock you've taken.
All of that complicates working with hashtables, so if you need that type of access, you should probably just use external locking.
Creating `argv` for zenity means we don't have to pass the building
blocks between threads which allows us to avoid deep copying some nested
structures. It also allows us to fail earlier in case of problems with
building the argument vector.
