The window may be initially maximized or made fullscreen by the window manager for various reasons, such as automatically declaring a window that precisely fills the usable desktop space as maximized, or a "kiosk-mode" automatically making the window fullscreen.
Don't redundantly make restored or unset fullscreen calls when initially showing a window, or the expected state can be unset.
It doesn't work well with Vulkan, and Vulkan windows may not have the Vulkan flag set in all circumstances, so only enable it if we explicitly know that OpenGL is being requested instead.
Moved the event handlers from SDL_CreateWindow to SDL_VideoInit
emscripten_set_mouseup_callback
emscripten_set_focus_callback
emscripten_set_blur_callback
emscripten_set_pointerlockchange_callback
emscripten_set_fullscreenchange_callback
emscripten_set_resize_callback
On non-compositing window managers, XIconifyWindow can trigger map/unmap events, which would toggle the window hidden/shown state. This should not be done, as a hidden window in SDL is equivalent to a withdrawn window in X, and SDL will try to set/reset state when it is shown again.
Unless the window is explicitly being withdrawn via X11_HideWindow(), set unmapped windows to the minimized/occluded state, and send a restored event when mapped again.
The taskbar list is invalid after OleUninitialize(), so make sure we clean it up first.
Also don't bother creating the taskbar list if we don't have any progress state
For some reason this locks up the Windows compositor when called by Steam. I'm disabling it for now until we understand why and whether this can cause issues for other applications as well.
The window failing to enter/exit fullscreen notifications don't necessarily imply anything about the actual state of the window. On failure, dump pending events, and don't presume anything about the current window state, as it will be handled by subsequent enter/leave notifications.
GNOME requires this to allow keyboard grabs on XWayland. Otherwise, XGrabKeyboard will still report success, but shortcuts won't be inhibited.
See 5f132f3975
The accelerated relative coordinates are always relative to the desktop resolution, and need to be scaled with emulated fullscreen resolutions for mouse movement to remain stable. Otherwise, pointer speeds will be too fast on emulated resolutions below the desktop resolution, and too slow on those above.
* Allow custom message boxes with colors and multiple buttons to work if Asyncify is enabled
* Keep old functionality of using alert when Asyncify is not available
* Update testmessage to allow for setting random colors as the color scheme of the message box
