Add support for minimum window size

[dusk125]

glfw has support for setting the smallest size of a resizable window with glfwSetWindowSizeLimits. This would add support for this function.

• [x] Add window configuration option for minimum/maximum size
• [x] Add method on window struct for setting the minimum/maximum size after window creation

[MarkKremer]

Adding the maximum size could be an easy addition as well.

[dusk125]

Adding the maximum size could be an easy addition as well.

I updated the acceptance criteria to include maximums, may as well include it as it's essentially free! Thanks

[bhperry]

Adding the maximum size could be an easy addition as well.

I updated the acceptance criteria to include maximums, may as well include it as it's essentially free! Thanks

Yep, same func for both in go-gl/glfw so may as well stick with that https://github.com/go-gl/glfw/blob/037f3cc74f2ab0b249928c4fc4b61e0f13befdb8/v3.3/glfw/window.go#L486C18-L486C31

Are you thinking we add something like BoundLimits pixel.Rect to WindowConfig as well?

[MarkKremer]

I'm new to pixel but I don't understand why WindowConfig.Bounds is a rect instead of only the width and height. And if you had this WindowConfig could have a MinSize and MaxSize which are also vecs.

[bhperry]

I'm new to pixel but I don't understand why WindowConfig.Bounds is a rect instead of only the width and height. And if you had this WindowConfig could have a MinSize and MaxSize which are also vecs.

You know.... that's a great point. At a glance window really only uses the bounds rect for width and height anyway.

[dusk125]

Yeah +1 for using the unused x,y components for the min size!

[MarkKremer]

I would do it separately. Because you have, min, max and default/initial.

[dusk125]

I would do it separately. Because you have, min, max and default/initial.

Ahh good call

[bhperry]

Maybe this should go on the v3 pile with color refactor? Change bounds to vec, and add min/max bound vecs.

[bhperry]

Assuming we validate there's no reason to keep bounds as a rect

[dusk125]

Assuming we validate there's no reason to keep bounds as a rect

The only thing I could think is we allow setting the initial window position with the x,y of the bounds, but I don't know if there's a use-case for that

[dusk125]

There's already a WindowConfig.Pos option... maybe in v3 we combine that into the bounds?

[bhperry]

hmmm yeah that could work.

Also realized a useful thing about having a rect for bounds is you get win.Bounds().Center(). Could of course add a win.Center() if we did decide to move to a Vec, but nice to get it free with rect.

[dusk125]

Oooo yeah good point....and I think that's why it's a rect! I mean, we could have the config option be a Vec and just convert it to a rect when the window is created