Over the past week or two I’ve encountered a handful of weird issues manipulating windows with SDL2 (see my other topic about strange window decorations here) but this one is a bit more serious. SDL_SetWindowPosition() does not appear to work at all on Fedora Linux 36 w/ GNOME. Perhaps it is an issue using Wayland over X Window Server or something else? Any one else experiencing similar issues?
Kind regards,
Sheridan
Per SDL2 Window decorations don't match desktop theme? , yes that would appear to be Wayland which does not support setting the window position.
Is it too much to ask that the main SDL2 documentation lists any platforms that do not support the specified functionality? For example SDL_SetWindowPosition() simply states that it is “available since SDL 2.0.0” but gives no clue that there are any backends with which it doesn’t work.
I can confirm that it is not too much to ask… I had the exact same thought not too long ago:
I’m not sure what the full list is, but I would take a wild guess that only Windows, Cocoa, and X11 support SetWindowPosition (and GetGlobalMouseState, for the same reasons). Once we know the full list it should be added to the wiki.
Any particular reason why Wayland is not supported? It seems to becoming more commonly adopted by mainline distros. Does it simply lack the ability for clients to reposition their windows or does libdecor/libSDL2 just lack the proper functionality? SDL_SetWindowPosition() isn’t a pointless function either, it seems to be the way to move your window to other displays for the purpose of setting fullscreen on that display. Thank you for the replies by the way 
Wayland is fully supported (we actually planned to make it the default globally but third parties needed more time), but the protocol does not allow setting window position or getting global states of any kind - this is meant to be a security feature, which does make sense… much as I love being able to center the window at startup it’s annoying to have windows and the cursor randomly flying around by an application that I didn’t want to give control to.
That being the case, it would seem to me that SDL needs a new facility for the user to change which display they want their fullscreen app to render on.
Wayland just lacks that functionality
In case of the window decorations it’s pure ignorance of Wayland and GNOME developers who for years have been insisting that server-side decorations are not needed and every application (or the UI framework it uses, like Gtk) should handle its own window decorations.
Regarding setting Window position and getting global mouse position it’s probably a security feature - an application can’t inspect input that’s on other windows, and it can’t move itself over other windows or things like that (which could also be used to “steal” input for other windows, think grabbing passwords etc)
As stated, the main concern here is that the user needs a way to choose which monitor/display to render their fullscreen app on. Security issues aside, I personally don’t see a practical need for SDL_SetWindowPosition outside of this.
Is the current recommended way that the user should drag their game/app window to the other monitor and then toggle fullscreen with SDL_SetWindowFullscreen()?
I haven’t used Wayland much yet, maybe
SDL_CreateWindow("Title", SDL_WINDOWPOS_UNDEFINED_DISPLAY(displayIdx), SDL_WINDOWPOS_UNDEFINED_DISPLAY(displayIdx), windowWidth, windowHeight, SDL_WINDOW_FULLSCREEN); works?
Destroying and recreating the window has the dangerous habit of trashing the associated GL context.
If the window already exists, I’d expect it to fullscreen on the display it’s currently on when switching to fullscreen.
No idea if that actually happens, it’s probably up the the window manager
It would be great actually if you could simply separate your GL/Metal/Vulkan context from whatever window you are rendering to, and assign it to another window. In theory this is what the SDL_Renderer abstraction is meant for, to separate the concept of the renderer and the display surface, and yet once a renderer and a window are bound together, there doesn’t seem to be anyway to detach them again.