We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Just to clarify:

On Wayland when using xdg_shell surfaces, window size constraints are communicated to the compositor using `set_min_size` and `set_max_size` requests. Setting both min_size and max_size to the same positive non-zero value furthermore indicates that the window is non-resizable.

Based on debug logs from markands' application, it can be seen that these requests are never issued, which means that compositor will not impose any size constraints.

The symptoms of this issue differ between compositors. Windowed compositors like GNOME will present the option to resize, but it will never have effect. Tiling compositors like Sway will not use the appropriate fixed-size floating container, but instead use an always resizable tiling container (in which the content will just not resize with it).

If window size constraints are present, even for resizable windows, then min_size/max_size should be set appropriately. Based on how small the symptoms are under windowed compositors like GNOME, this is an understandable oversight.

Note that I have not verified the application that exhibited this issue, and cannot comment on its correctness with regards to use of SDL2's API. I am merely commenting on the Wayland protocol log, which lacked the necessary requests.

Created attachment 4048 [details]
First shot at using set_(min|max)_size


Here's a first shot at fixing this. I haven't even tried to compile this patch, so assume this isn't the final attempt on the topic.

This marks the min/max size of the window at creation time, if the window wasn't created with the SDL_WINDOW_RESIZABLE flag.

Since it uses the same interfaces, this also fills in Wayland support for SDL_SetWindowResizable, SDL_SetWindowMinimumSize, and SDL_SetWindowMaximumSize.

It's not clear to me if we have to wait for an initial configure event before setting a min/max, but I think not. We have code to deal with other details if this is necessary, but it's cleaner if we can just handle this in Wayland_CreateWindow() and be done with it.

Obviously this needs xdg_shell support (or zxdg_shell_v6 on older Wayland installs). If those are missing, SDL won't do anything here and you're at the mercy of the system.

--ryan.

I'm assigning this bug to myself, but I'd appreciate it if someone would try that patch and send in an update with any obvious mistakes fixed.  :)

--ryan.

Hello,

Your patch was almost correct, It looks like you forgot to use minw, minh, maxw, maxh because the compiler emitted some warnings. I fixed it. See the attached patch.

So it immediately opens in floating mode in sway which also indicate it's not resizable and I'm unable to resize it :-)

What's strange though, is that the configure shows a different size.

[ 76133.215]  -> xdg_toplevel@25.set_min_size(500, 500)
[ 76133.224]  -> xdg_toplevel@25.set_max_size(500, 500)
[ 76133.347]  -> zxdg_decoration_manager_v1@11.get_toplevel_decoration(new id zxdg_toplevel_decoration_v1@26, xdg_toplevel@25)
[ 76133.360]  -> zxdg_toplevel_decoration_v1@26.set_mode(2)
[ 76133.649] xdg_toplevel@25.configure(0, 0, array)
[ 76133.716]  -> xdg_toplevel@25.set_title("test")
[ 76133.728]  -> xdg_toplevel@25.unset_fullscreen()
[ 76161.773] xdg_toplevel@25.configure(500, 500, array)
[ 79188.413] xdg_toplevel@25.configure(496, 477, array)

In fact, I'm able to resize it a little bit to a smaller size which seems to be 496, 477. But after that I'm no longer able to resize it at all.

Created attachment 4049 [details]
updated patch

Created attachment 4050 [details]
before trying to resize

Created attachment 4051 [details]
after trying to resize

As you can see in the two screenshots. The first one is correct, the window has the good size and starts floating (which sway does when windows are not resizable).

On the second screenshot, you can see that the SDL view exceeds the sway window frame a little bit after have tried to resize it. And I suspect this is because there are different configured sized as shown in my previous comment (496x477 vs 500x500). Looking at the black borders exceeding the frame it looks to be the case. Afterwards, it's impossible to resize it at all.