Add SDL_ShowWindowSystemMenu() to display the system-level menu for windows. Typically, this is done by right-clicking on the system provided window decorations, however, if an application is rendering its own client-side decorations, there is currently no way to display it. This menu is provided by the system and can provide privileged desktop functionality such as moving or pinning a window to a specific workspace or display, setting the always-on-top property, or taking screenshots. In many cases, there are no APIs which allow applications to perform these actions manually.
Implemented for Wayland via functionality provided by the xdg_toplevel protocol, Win32 via the undocumented message 0x313 (typically called WM_POPUPSYSTEMMENU), and X11 via the "_GTK_SHOW_WINDOW_MENU" atom (supported in GNOME and KDE).
This rips up the entire SDL audio subsystem! While we still feed the audio device from a separate thread, the audio callback into the app is now gone a totally optional alternative.
Now the app will bind an SDL_AudioStream to a given device and feed data to it. As many streams as one likes can be bound to a device; SDL will mix them all into a single buffer and feed the device from there.
So not only does this function as a basic mixer, it also means that multiple device opens are handled seamlessly (so if you want to open the device for your game, but you also link to a library that provides VoIP and it wants to open the device separately, you don't have to worry about stepping on each other, or that the OS will fail to allow multiple opens of the same device, etc).
Merged from pull request #7704.
Fixes#7379.
Reference Issue #6889.
Reference Issue #6632.
Render targets are a core feature of SDL 3.0, so this flag has been removed.
The OpenGL ES renderer still doesn't support them, but we'll deal with that later.
Fixes https://github.com/libsdl-org/SDL/issues/8059
Now you open an audio device and attach streams, as planned, but each
open generates a new logical device. Each logical device has its own
streams that are managed as a group, but all streams on all logical
devices are mixed into a single buffer for a single OS-level open of
the physical device.
This allows multiple opens of a device that won't interfere with each
other and also clean up just what the opener assigned to their logical
device, so all their streams will go away on close but other opens will
continue to mix as they were.
More or less, this makes things work as expected at the app level, but
also gives them the power to group audio streams, and (once added) pause
them all at once, etc.
main features:
- No more sdl-build-options/sdl-shared-build-options/sdl-global-options
- Dependency information is stored on SDL3-collector for sdl3.pc
- Use helper functions to modify the SDL targets;
- sdl_sources to add sources
- sdl_glob_sources to add glob soruces
- sdl_link_dependency to add a link dependency that might also
appear in sdl3.pc/SDL3Config.cmake
- sdl_compile_definitions to add macro's
- sdl_compile_options for compile options
- sdl_include_directories for include directories
They avoid repeated checks for existence of the SDL targets
- A nice feature of the previous is the ability to generate
a sdl3.pc or SDL3Config.cmake that describes its dependencies
accurately.
various:
- remove duplicate libc symbol list
- add CheckVulkan
- remove unused HAVE_MPROTECT
- add checks for getpagesize
Adds the SDL_EVENT_WINDOW_OCCLUDED events and the window flag SDL_WINDOW_OCCLUDED to report when the window occlusion state has changed, so that the application can take appropriate measures, as it may wish to suspend drawing, throttle, or otherwise behave in a more energy efficient manner when the window is not visible. When the window is no longer occluded, the SDL_EVENT_WINDOW_EXPOSED event is sent and the occlusion flag is cleared.
This is handled on macOS via the window occlusion state event (available as of 10.9), and via the xdg-shell protocol on Wayland (version 6, wayland-protocols 1.32, passed through in libdecor 0.1.2).
Also renamed most cases of SDL_GAMEPAD_TYPE_UNKNOWN to SDL_GAMEPAD_TYPE_STANDARD, and SDL_GetGamepadType() will return SDL_GAMEPAD_TYPE_UNKNOWN only if the gamepad is invalid.
Removing SDL_GAMEPAD_TYPE_VIRTUAL allows a virtual controller to emulate another gamepad type. The other controller types can be treated as generic controllers by applications without special glyph or functionality treatment.
This will simplify the X11 and Wayland implementations, which were doing that under the hood, and makes application interaction between the two APIs consistent.
SDL Wiki Bot
meyraud705
Frank Praznik
Ryan C. Gordon
Semphris
Sam Lantinga
Starbuck5
Anonymous Maarten
Sylvain