Try to match the requested video mode when a fullscreen window is moved to a new display, or it may not be returned to the requested mode if it is moved to a display with no matching mode, then back to the original display.
The behavior when minimizing a window on Wayland is compositor dependent and clients are not informed when windows enter or leave the minimized state, however we can assume that, when receiving a minimize request from the application, the minimized window should set and keep the minimized status flag until the window regains focus.
This is required when attaching a renderer context to a minimized window, as the renderer creation process destroys and recreates the target window, and without retaining the minimized flag, the recreated window will lose the minimized state.
Hiding the decorations while not unreferencing the frame was a workaround for an internal libdecor use-after-free bug that was fixed some time ago. Revert to unreferencing the window when hiding to ensure that it is properly destroyed.
Reverts dd2e318
this fix x11 backend to correctly pass video_setWindowCenteredOnDisplay()
- get border values early (eg status bar)
- wait for size/position change to get valid values
Fix set topleft is client rendering area
This isn't the behavior on Windows, and this should probably be an application defined behavior.
If we decide we want this globally, it should probably be implemented at a higher level in SDL_OnWindowFocusLost(), and properly handle the transition of focus to a child window.
The xdg-output spec was updated to clarify its usage rules, and what was previously thought to be a bug is actually valid behavior. Gnome, when not using 'scale-monitor-framebuffer', does not scale the viewport of the display in the global compositor space, and thus the physical and logical sizes of the display will match. This value still needs to be divided by the integer scale value to get the logical output dimensions in screen units though.
Don't throttle window updates until the first swap has occurred, as the window won't actually be shown or receive the frame callback until that point and this causes new window creation to have a full 1 second delay.
Update the popup window creation documentation with additional info, remove the SDL_WINDOW_MOUSE_GRABBED flag check since it isn't a valid window creation flag and will be removed automatically elsewhere, and check for and remove the explicit skip taskbar and borderless flags since they are implicit for popup windows.
Disallow additional window operations on popups where they have no functionality or otherwise don't make sense:
- Popups cannot be set as modal to other windows (they're already child windows of a parent)
- Other windows cannot be set as modal of popups
- Popups cannot explicitly grab the mouse/keyboard (the topmost popup menu takes the keyboard focus implicitly)
- Popups cannot flash or be raised
Set the timeout max to one second from the current time or presentation time will always be greater than the timeout and the application will run unthrottled.
Don't use the cached floating window size for maximized or tiled windows. Fixes the initial window size when creating a window with the maximized flag set.