slint-ui
`Window` component's `max-...` too big
max-width and max-height of a component inheriting Window are 340282350000000000000000000000000000000. But, at least on Windows 10, windows can maximally be resized manually to about the size of the virtual screen. This means you can programmatically set width and height to very large values, then try to manually resize the window, and the window will suddenly jump to the smaller size of the virtual screen, which easily leads to the window jumping off-screen without the possibility to get it back via mouse.
Here's a small demo project that allows you to trigger the problem: max-too-big-demo.zip.
If you'd make it so that Windows could maximally be programmatically resized to the size also applying in the context of manual resizing, couldn't there be conflicts with big minimum sizes of the content? E.g., if someone used to big screens designed a UI that ends up being displayed on a tiny screen? In my test, at least also setting Slint's min-... properties didn't increase the maximum manual-resizing size; but perhaps, the possibilities Windows offers just aren't exhaustively made use of by Slint/winit. Another strategy could be to just crop the UI at the right and bottom sides, if its content has a minimum size that doesn't harmonize with the maximum size enforced by the OS.
Not sure whether this is because we set the maximum to the biggest possible value we can set or because winit provides us with that as the maximum window size. So this might be upstream.
When the max size is bigger than i32::MAX, we don't set a maximum size to the window manager.
But i'm not sure what this issue is about. What should we do in Slint?
I read the bug report as we should not ever report a max size that is bigger than the may size the window manager will actually be able to handle.
The max-width and max-height of any element in Slint is the constraint that the layout system should apply to the element. It is meant to be communicated from the element, to the "outside" (so the windowing system) Not the other way around.
So I don't think the bug is valid.