Adds SDL_HINT_VIDEO_MAC_FULLSCREEN_MENU_VISIBILITY to control whether or not the menu can be accessed when the cursor is moved to the top of the screen when a window is in fullscreen spaces mode.
The three values are true, false, and 'auto' (default), with auto resulting in a hidden menu if fullscreen was toggled programmatically, and the menu being accessible if fullscreen was toggled via the button on the window title bar, so the user has an easy way back out of fullscreen if the client app/game doesn't have a readily available option to toggle it.
Add SDL keycodes for keys found commonly found in the default Xkb layout, such as left tab and compose, and keys frequently used for custom modifiers such as Meta, Hyper, and Level5 Shift.
As these keys aren't Unicode code points and don't have associated scancodes (at least on modern keyboards), they are placed in the new extended key code space, with bit 30 set as a flag.
Adds support for Mod3, which is usually Level 5 shift, but can vary, as well as not altering the functionality of the more esoteric modifier keys, such as meta and hyper.
This hint defaults on, enabling advanced controller features.
This replaces SDL_HINT_JOYSTICK_HIDAPI_PS4_RUMBLE and SDL_HINT_JOYSTICK_HIDAPI_PS5_RUMBLE, and is supported by PlayStation and Nintendo Switch controllers.
Fixes https://github.com/libsdl-org/SDL/issues/10086
If you're not using SDL for video you won't get raw input messages without this hint, and this is tripping up enough people it makes sense to have this enabled by default. There isn't much downside to this, other than having another thread processing Xbox controller input.
Fixes https://github.com/libsdl-org/SDL/issues/10576
Now (only in the generic backend, where it is implemented), this hint is
always respected. Previously it would only be used if no windows were created,
to help reduce CPU load on things like loopwave.
Since it's always used now, the default has changed from 60 (Hz) to 0 (run as
fast as possible). Things like loopwave should still likely force this way
lower than the previous default (and already do: loopwave explicitly sets it
to 5).
The hint can now also be set to "waitevent" which will cause SDL_AppIterate
to only be called after new events have arrived, for apps that are entirely
driven by input and want to consume (almost) no power or CPU time until then.
Fixes#11093.
Fixes#11387.
SDL_HINT_QUIT_ON_LAST_WINDOW_CLOSE will not fire if there are active tray icons. This impacts only applications that create tray icons, and that at least one icon outlives the last visible top-level window. SDL_EVENT_QUIT will fire when the last active tray is destroyed if there are no active windows.
This can cause misunderstanding about how texture creation works, as seen in https://github.com/libsdl-org/SDL/issues/9504. Instead let people check the error for more information on why creation may have failed.
Currently, `SDL_DEFAULT_ASSERT_LEVEL` is commented out by CMake when its value is 0, setting the assertions level to the default value instead of disabling them.
This change:
- defines `SDL_DEFAULT_ASSERT_LEVEL_CONFIGURED` when its value is non-zero.
- defines `SDL_DEFAULT_ASSERT_LEVEL`, regardless of its value, when `SDL_DEFAULT_ASSERT_LEVEL_CONFIGURED` is defined.
It's too close the 3.2.0 release for an API change like this.
If/when we re-add these, some things for consideration:
* What use cases does this enable that aren't currently possible?
* What cross-platform API guarantees do we make about the availability of these events? e.g. do we try to simulate them where raw input isn't actually available?
* How is this different from the existing relative mode, and how do we clearly explain when you want these events vs wanting relative mode?
Notes from @expikr:
First observation: the reason I originally passed denominators instead of multipliers was because some rational values cannot be exactly represented by floats (e.g 1/120) so instead let the end-developer decide how to do the dividing themselves. It was the reason why it was using split values with an integer numerator to begin with, instead of having both as floats or even just normalize it in advance.
On the other hand, passing them as multipliers might have hypothetical uses for dynamically passing end-user controlled scaling in a transparent manner without coupling? (Though in that case why not just do that as additional fields appended to `motion` structs in an API-compatible layout?)
So it’s somewhat of a philosophical judgement of what this API of optional availability do we intend for it to present itself as:
- should it be a bit-perfect escape hatch with the absolute minimally-denominal abstraction over platform details just enough to be able to serve the full information (á la HIDPIAPI),
- or a renewed ergonomic API for splitting relative motion from cursor motion (in light of The Great Warping Purge) so that it is unburdened by legacy RelativeMode state machines, in which case it would be more appropriate to just call it `RELATIVE` instead of `RAW` and should be added alongside another new event purely for cursor events?
This alternate API stream was conceived in the context of preserving compatibility of the existing RelativeMode state machine by adding an escape hatch. So given the same context, my taste leans towards the former designation.
However, as The Great Warping Purge has made it potentially viable to do so, if I were allowed to break ABI by nuking the RelativeMode state machine entirely, I would prefer the latter designation unified as one of three separate components split from the old state machine, each independently controlled by platform-dependent availability without any state switching of a leaky melting pot:
- cursor visibility controls (if platform has cursor)
- cursor motion events (if platform has cursor)
- relative motion events (if the platform reports hardware motion)
Almost everything in this header is now documented! The remaining gaps are
literal C runtime wrappers like SDL_strdup, and the analyzer macros like
SDL_INOUT_Z_CAP.
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`
- 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.
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.
This can be reverted if a toolchain arrives that can handle C99 features like
variables declared in the middle of a scope, but for now we literally can't
compile SDL3 for this platform.
Fixes#11243.
This is a hard requirement on Apple platforms and while most other platforms don't have a concept of main thread, all video and input functions should be called on the same thread.