LR"SDL_SetWindowPosition() failed: wayland cannot position non-popup windows"
the more you know.
Daniel Ludwig@lritter "How DARE YOU telling me where to place your window at!"
@code_disaster it could be used for shenanigans but still, strikes me as needlessly preemptive.
radgeRayden@lritter @code_disaster I reckon this is to standardize alternative windowing situations like tiling window managers, though it's of course questionable that "just ignore it" wasn't good enough
Daniel Gibson@lritter
This is why the multi-viewports feature of Dear ImGuis Docking branch doesn't work with Wayland: usually it lets you seamlessly drag ImGui "windows" out of your application OS-level Window by creating a new OS-level Window at the same position when going over the window border (and merges it back in when dragging it back) - obviously that doesn't work with Wayland because you neither can set a windows position nor *get* a windows global position
This is why the multi-viewports feature of Dear ImGuis Docking branch doesn't work with Wayland: usually it lets you seamlessly drag ImGui "windows" out of your application OS-level Window by creating a new OS-level Window at the same position when going over the window border (and merges it back in when dragging it back) - obviously that doesn't work with Wayland because you neither can set a windows position nor *get* a windows global position
@Doomed_Daniel which would mean any other app that wanted to do this would not work either.
regrettable, but there are workarounds. firefox for instance has a similar problem to deal with when dragging/dropping browser tabs.
@lritter yes, to some degree you could work around it (with extremely wayland-specific code that works very different to all other platforms), like using features meant for drag'n'drop for the "dragging windows back in" feature, that's what browsers use for moving tabs between windows AFAIK
@Doomed_Daniel fugly but what can you do besides kidnapping someone from the wayland team and making them implement this at gunpoint
@lritter dunno.. tell people to run your application through xwayland?
@Doomed_Daniel it's SDL. it runs on whatever is there.
wait what does xwayland do?
@lritter xwayland is the thing that lets you run X11 applications on wayland (it's a subset of X.org)
if you tell SDL to use its X11 backend on a wayland desktop, xwayland will be used (if installed) - and then moving windows around etc works
if you tell SDL to use its X11 backend on a wayland desktop, xwayland will be used (if installed) - and then moving windows around etc works
@Doomed_Daniel wait xwayland can position windows on wayland? how is that fair? share with the rest of us, xwayland!
@lritter xwayland can also see the global mouse cursor position - but only while the cursor is on an X11 window.
which is why a popular check for whether something is running through xwayland or "natively" is running xeyes and see if the eyes follow the cursor when over the other application in question
which is why a popular check for whether something is running through xwayland or "natively" is running xeyes and see if the eyes follow the cursor when over the other application in question
Andre Weissflog@lritter @Doomed_Daniel tbh, I just treat XWayland as the missing 'window system layer' between Wayland and non-Qt/GTK desktop apps which provides must-have features like a standardized window chrome and everything else expected of a desktop window system but not universally provided by Wayland implementations.
A shame that this requires coding against the X11 APIs (which suck ass), a much smaller client library that's installed on each Linux desktop system alongside Wayland would be nicer.