glfw: 'dont_care' value limitation in Window.setSizeLimits #119

Closed
opened 2021-12-07 13:43:11 +00:00 by InKryption · 2 comments
InKryption commented 2021-12-07 13:43:11 +00:00 (Migrated from github.com)

Currently, the function Window.setSizeLimits takes as parameters the window handle, and two Window.Sizes named 'min' and 'max'. Window.Size is a struct with two fields 'width' and 'height', each with type usize; a limitation I noticed with this setup is that, unlike what is said in the doc-comment of the function in question, there is no way to pass glfw.dont_care as a value to indicate "I don't care what the min/max value of this dimension is relative to the others", because GLFW defines glfw.dont_care (GLFW_DONT_CARE) as a negative value, which can't be represented by a usize.

Possible approaches that come to mind:

  • Make an alternative 'SizeSigned' struct with signed integer 'width' and 'height' fields, which would then allow directly expressing the same usage of the GLFW API as plain old GLFW.
  • Make an alternative 'SizeOptional' struct with optional integer 'width' and 'height' fields, which could then be set to null to express the idea of glfw.dont_care (in the implementation it would be something like min.width orelse glfw.dont_care perhaps) in the Zig style.

I'm personally in favor of the second solution, but can see the value in the first.

It would also probably be a good idea to take this in consideration for the rest of the codebase, wherever else the concept of glfw.dont_care applies.

Currently, the function `Window.setSizeLimits` takes as parameters the window handle, and two `Window.Size`s named 'min' and 'max'. `Window.Size` is a struct with two fields 'width' and 'height', each with type `usize`; a limitation I noticed with this setup is that, unlike what is said in the doc-comment of the function in question, there is no way to pass `glfw.dont_care` as a value to indicate "I don't care what the min/max value of this dimension is relative to the others", because GLFW defines `glfw.dont_care` (`GLFW_DONT_CARE`) as a negative value, which can't be represented by a `usize`. Possible approaches that come to mind: * Make an alternative 'SizeSigned' struct with signed integer 'width' and 'height' fields, which would then allow directly expressing the same usage of the GLFW API as plain old GLFW. * Make an alternative 'SizeOptional' struct with optional integer 'width' and 'height' fields, which could then be set to `null` to express the idea of `glfw.dont_care` (in the implementation it would be something like `min.width orelse glfw.dont_care` perhaps) in the Zig style. I'm personally in favor of the second solution, but can see the value in the first. It would also probably be a good idea to take this in consideration for the rest of the codebase, wherever else the concept of `glfw.dont_care` applies.
meshula commented 2021-12-08 02:27:06 +00:00 (Migrated from github.com)

I'd vote for the second as well, negative values as sentinel values are so 1995.

I'd vote for the second as well, negative values as sentinel values are so 1995.
emidoots commented 2021-12-09 05:34:08 +00:00 (Migrated from github.com)

I see. I had missed that GLFW_DONT_CARE is a valid parameter here, thanks for catching this!

The second solution sounds perfect to me. And definitely agree about vetting for other possible missed places we might need to express GLFW_DONT_CARE

I see. I had missed that `GLFW_DONT_CARE` is a valid parameter here, thanks for catching this! The second solution sounds perfect to me. And definitely agree about vetting for other possible missed places we might need to express `GLFW_DONT_CARE`
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
hexops/mach#119
No description provided.