I am not sure why this would be a bug. I think internal code has the same restriction. The code should set the min/max if it wants to change it.

I am not sure why this would be a bug. I think internal code has the same restriction. The code should set the min/max if it wants to change it.

From the viewpoint of a plugin developer that does not know how the implementation: They create a window, specifying width and height, but not minWidth/maxWidth and minHeight/maxHeight. Width/height seems to be writable, so they try to resize the window, which does not work. There is no hint at all that the min/max values are the reason for that.

In particular, the min/max values are optional when creating a window, but are still internally set to the width/height value. This is not transparent at all.

@Sadret would better documentation help? Technically the width and height are getting set, it's just that the next game tick will update it back based on min and max. This is perhaps useful if you want to increase it on a resizable window - but keep the constraints of the min/max size. Internal windows would have to do exactly the same thing.

For plug-in developers this can be really confusing, since they don't set a minimal or maximum size anywhere. Wouldn't it be better to simply set the min to zero and max to 2^31-1 to get around this?

When I created the issue and the PR, I only thought about custom windows and did not realize that it would also effect vanilla windows. So I have to overthink.

The main problem I have with the current state is this: When I create a window using only width and height, I am expecting to be able to change width and height because they are marked in the documentation as mutable. But this is not the case (at least not without the min/max workaround). So, in the current state, everyone who wants to use this part of the API either has to ask or has to look into the implementation, and even then, a workaround should not be necessary.

This is why I submitted the issue and PR. I still think that behaviour-wise the changes provide the best solution for custom windows. Implementation-wise it might be considered unclean/hack though. For regular windows, I think that the behaviour is fine, I do not really see a problem with plugins being able to change the size of non-resizable windows. Is there an argument against it? It will probably never happen anyway, but if a plugin really wants to misuse it, there are already much better ways to provide bad user experience.

Also, keep in mind that the behaviour of resizable windows is not effected at all.

Otherwise, as @IntelOrca suggested, adding documentation is a valid option. Something like this:

• width: When writing to this property, the value will be clamped to [minWidth,maxWidth]
• minWidth, maxWidth: If unspecified during window creation, they default to width

Same for height, of course. This will work, but I personally think the current behaviour is a bit tedious for plugin devs, so I would rather change the behaviour than the documentation.

Summary of my (subjective) viewpoint:

• If a dev wants to change the size of their (non-resizable) custom window, then window.width = value should do the trick.
• It is not a problem if plugins can change the size of "non-resizable" windows.

What are your thoughts on this?

For plug-in developers this can be really confusing, since they don't set a minimal or maximum size anywhere. Wouldn't it be better to simply set the min to zero and max to 2^31-1 to get around this?

The problem with this approach is that a custom window is handled as resizable if the min and max values are different. So we would need to introduce a new boolean resizable and use that during window creation, which is definitely also possible wihtout much overhead.

Given this behaviour only affects windows that can't resize, I am happy with it. I think the documentation should still be updated to explain how it works.

I added documentation to Window and WindowDesc. Let me know what you think.
I also increased the api version.