Applications might override WM_WINDOWPOSCHANGING which would prevent us from getting the correct window state.
This also fixes cases where the window doesn't get WM_SHOWWINDOW, as described in Raymond Chen's blog post:
https://devblogs.microsoft.com/oldnewthing/20080115-00/?p=23813
Allow for the creation of SDL windows with a roleless surface that applications can use for their own purposes, such as with a windowing protocol other than XDG toplevel.
The property `wayland.surface_role_custom` will create a window with a surface that SDL can render to and handles input for, but is not associated with a toplevel window, so applications can use it for their own, custom purposes (e.g. wlr_layer_shell).
A test/minimal example is included in tests/testwaylandcustom.c
A Wayland registry object can only have one listener attached at a time, so an application attempting to use the backend SDL registry object for its own purposes will just result in an error. Remove this property, as it is of no use to applications and will only result in errors.
If an application needs the registry, it needs to get the wl_display object via `SDL.window.wayland.display` and use wl_display_get_registry() to create a new registry object that it can attach its own listeners to.
If the xdg_wm_base protocol isn't present, the window won't be assigned a valid surface type at creation time, which makes these checks redundant.
The libdecor path was already cleaned up in this manner some time ago.
- Child windows are added and removed dynamically from the window hierarchy when they're shown/hidden. Adding a hidden child window to a visible
parent is fine, but adding a hidden child window to a hidden parent will cause the child to show when the parent window is shown as it's still a part of
the window hierarchy.
- For some reason, not adding the child window to the parent entirely causes the child to not focus correctly the first time it's shown. Adding then immediately
calling orderOut to remove the child window from the hierarchy does work correctly so we do this to work around the weird issue.
For some reason, fullscreen space windows won't get any mouse button events unless the NSWindowStyleMaskTitled flag is set when entering fullscreen, even though they successfully become key and receive mouse motion events. Make sure the flag is always set when entering fullscreen space state.
It turns out that when you enable raw input and then process Windows messages, you'll get the currently pending input in GetRawInputBuffer(), and you'll get any new input that occurs while processing messages as WM_INPUT.
The fix for this is to create a dedicated thread to handle raw input and only use GetRawInputBuffer() in that thread. A nice side effect of this is that we'll get mouse input at the lowest latency possible, but raw mouse events will now occur on a separate thread, outside of the normal event loop processing.
Improved fix for https://github.com/libsdl-org/SDL/issues/8756
Send fullscreen enter/leave events, which will implicitly update the fullscreen flag. Manually setting the flag will suppress attempts to send the events later, as the flag is used for deduplication purposes in the event code.
Matches the one in `GetMouseMessageSource()`.
From my testing on Windows 11, the lower 8 bits in touch events cycle
trough the values 0x8c-0x95 in order.
The call stack is:
We want to use this instead of the desktop mode because the view may be in a different orientation than the device orientation, which the desktop mode is based on.
