External windows may call this to update the renderer size, but not pump SDL events, either by syncing or running an event loop, so the size event always needs to be synthesized for external windows. If it is wrong, the true size will be sent if/when events are processed.
External windows often handle their own events, and SDL implicitly processing events during synchronization can be unexpected and cause issues. For requests that don't change the window state beyond size or position, use the legacy synchronization method that synthesizes events from the window attributes without processing events.
This reverts commit 0c8ddc1f0a.
The real bug here is that XWayland isn't sending us a display disconnected event, which will be handled in the next commit.
Openbox doesn't send size events when entering fullscreen, so they must be synthesized. This is not desirable on any other window manager, as it can break fullscreen positioning on multi-monitor configurations.
Use the modifier state supplied with key events to track the system modifier state instead of relying on the state returned by XQueryPointer(), which can be racy when used with automated text entry.
When the mouse is grabbed, the X server sends mouse events only to the grabbing client, and XInput2 events for the master device are not delivered.
We should consider using the window mouse rect confinement instead of a true X server grab for SDL mouse grab functionality.
An undefined position means that the window manager can handle placement, so SDL shouldn't override that by forcing a position when showing a window.
Allows for removing a fair bit of now-unnecessary code as well.
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, as well as not altering the functionality of the more esoteric modifier keys, such as meta and hyper.
Also use the system modifier state instead of setting them based on key presses, which may be incorrect due to remapping, or toggled in some other manner.
Find the toplevel parent window, not the absolute highest toplevel window in the hierarchy, when positioning and adjusting the focus of popup windows.
Fixes a leftover case from when toplevel windows couldn't be parented to other toplevels.
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)
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.
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.
Unless there are pending client requested window coordinates, such as in the case where the position is set followed by immediately by entering fullscreen, prefer the true window coordinates as sent by the window manager to select a fullscreen display.
Fixes the case where, if the window manager moves an already maximized window to another display, the window would be made fullscreen on the wrong display since the last floating coordinates would be used.
