Allow for Limiting (Max & Min) Window Size

[eXpl0it3r]

While the old trick of resizing the window to the min/max allowed size after the sf::Event::Resize event, there are at least two issues with it:

• The user can during the dragging go below or above the set limits (see also #2406), which might be undesired can cause a lot of unnecessary recalculations or having to support this edge case in your application code.
  
• Due to X11's nature of being async, this can cause some odd behavior with certain window managers (see #2124) and the conclusion out of #2378 is, that it's basically impossible to fix, unless there's a minimum (or maximum) size defined beforehand.

Beyond potential API bloat, I don't really see an argument against having something like sf::Window::setMinimumSize(sf::Vector2u) & sf::Window::setMaximumSize(sf::Vector2u). If the OS doesn't natively support such a functionality, it's also pretty easy to simulate it the "old-school" way with the resize event.

Thoughts from others?

[Thrasher]

A way to specify a minimize window size would be great. The layout of your program is prone to break below a specific size so it makes sense to prohibit making it smaller than whatever that size is. I'm not sure what the use case of a maximum size is but I'm open to adding that interface.

My impression is that the X11 experiments about minimum window sizes showed that it was hard to get to get right. You say "it's basically impossible to fix, unless there's a minimum (or maximum) size defined beforehand.". Can you explain? If adding this API let us fix the X11 resizing issues that would be great.

[eXpl0it3r]

You say "it's basically impossible to fix, unless there's a minimum (or maximum) size defined beforehand.". Can you explain? If adding this API let us fix the X11 resizing issues that would be great.

You're fighting an async protocol with synchronous calls.
There are multiple reasons why having a min window size would fix this:

• As you can set a min window size, there's basically no reason for calling setSize right after a resize, which is the issue to begin with, where the async X11 calls, aren't yet fully up to date (at least that's how I understand it)
• By having set a min window size, the code can be optimized to continuously check the current size, instead of just once (or with the fix in a loop for some time) when calling setSize, meaning even if the size for some reason was wrongly set, the next incoming event could trigger a correction according to the set min window size

Hope that made things a bit clearer, if not, please let me know.

[dogunbound]

The real issue is that X11 refuses to resize the window if the user is still dragging it. This is how the control flow works:

This all happens in milliseconds:
X11 performs a window resize when a user drags the window borders. Then X11 puts a resized event onto the event queue. SFML puts that event onto its own event queue. The program polls for events from SFML's event queue. The program notices that the resize made the window too small; therefore, it will send a set size to SFML. SFML sends the set size parameters to X11. X11 tries to set the size of the window, but can't because the user is still holding onto the window border.

If we could force the user to not grab onto the border, the set size function would work seamlessly. Hypothetically speaking if the user lets go of the window between the time the window actually gets resized and X11 trying to set the size of the window with X11ResizeWindow, it would work fine.

Overall, the real solution is to have a min size and max size function. All other window APIs do this (godot, sdl, etc...)

[Thrasher]

https://github.com/SFML/SFML/pull/2519

Work on this is well underway

[Thrasher]

https://github.com/SFML/SFML/pull/2519

This PR is feature-complete and ready for testing and scrutiny.