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.
It's not intuitive from a developer's point of view that you wouldn't get these events. If they're impacting performance they can be explicitly disabled for applications that don't want them.
When a hardware keyboard is attached, it can take over 100 ms for the keyboard event to generate text input. In that case we want to record that we recently received a keyboard event so we don't synthesize duplicate virtual key press/release events for the input text.
This is another attempt to make sure we don't cause beeps from unhandled key presses while still allowing full text input functionalty.
If this isn't selective enough, we might need to go up the responder chain to see what's going to handle the event before passing it along.
Fixes https://github.com/libsdl-org/SDL/pull/6962
When a hardware keyboard is attached to an iPad, you can easily trigger a set of on-screen keyboard transitions that will take place over time, and we need to track whether we're currently showing or hiding the keyboard and make sure we don't clobber the existing state during those transitions.
Testing:
* Connected a hardware keyboard to an iPad
* Launched checkkeys
* Noted the keyboard bar was active at the bottom of the screen and text input was active
* Tapped with both fingers to quickly toggle text input off and back on
* Noted the keyboard bar slid down and then back up, and text input was active
* Tapped on the keyboard bar to bring up the full on-screen keyboard and then closed it so the keyboard bar was still active, and text input was still active
* Tapped on the screen to turn text input off, noted the keyboard bar slid down
* Tapped with both fingers to quickly toggle text input on and back off
* Noted that the keyboard bar slid up and then back down, and text input was inactive
* Tapped on the screen to turn text input on, tapped on the keyboard bar to bring up the full on-screen keyboard, and text input was active
* Pressed a key on the physical keyboard, the on-screen keyboard closed, the key press and release was delivered (with no text input) and then the keyboard bar slid up, and text input was active again
Fixes https://github.com/libsdl-org/SDL/issues/7979
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
This is allegedly lower-latency than the AAudioStream_write interface,
but more importantly, it let me set this up to block in WaitDevice.
Also turned on the low-latency performance mode, which trades battery life
for a more efficient audio thread to some unspecified degree.
SDL Wiki Bot
Frank Praznik
Ryan C. Gordon
Sam Lantinga
Ozkan Sezer
Anonymous Maarten
Semphris