glfw: 'dont_care' value limitation in Window.setSizeLimits #119
Labels
No labels
CI
all
basisu
blog
bug
build
contributor-friendly
core
correctness
deferred
dev
direct3d-headers
docs
driver-os-issue
duplicate
dxcompiler
editor
examples
experiment
feature-idea
feedback
flac
freetype
gamemode
gkurve
glfw
gpu
gpu-dawn
harfbuzz
help welcome
in-progress
infrastructure
invalid
libmach
linux-audio-headers
long-term
mach
mach.gfx
mach.math
mach.physics
mach.testing
model3d
needs-triage
object
opengl-headers
opus
os/linux
os/macos
os/wasm
os/windows
package-manager
priority
proposal
proposal-accepted
question
roadmap
slipped
stability
sysaudio
sysgpu
sysjs
validating-fix
vulkan-zig-generated
wayland-headers
website
wontfix
wrench
www
x11-headers
xcode-frameworks
zig-update
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
hexops/mach#119
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Currently, the function
Window.setSizeLimitstakes as parameters the window handle, and twoWindow.Sizes named 'min' and 'max'.Window.Sizeis a struct with two fields 'width' and 'height', each with typeusize; 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 passglfw.dont_careas a value to indicate "I don't care what the min/max value of this dimension is relative to the others", because GLFW definesglfw.dont_care(GLFW_DONT_CARE) as a negative value, which can't be represented by ausize.Possible approaches that come to mind:
nullto express the idea ofglfw.dont_care(in the implementation it would be something likemin.width orelse glfw.dont_careperhaps) 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_careapplies.I'd vote for the second as well, negative values as sentinel values are so 1995.
I see. I had missed that
GLFW_DONT_CAREis 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