-
-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
glfw: Friendlier window creation #65
Comments
I think this ties in nicely to what #61 is trying to accomplish, by removing the redundancy of access to |
I think if we get a couple more of these types of ideas, then it would be worth creating a glfw repo with a more zig friendly API and keep the current repo as is. There are of course some "zigified" concepts already in the project i.e changes related to issue #37 so the trade-off between QoL and too much of a deviation is hard to define currently. Issue #61 and this issue does change the overall "look" of user code so I guess that kinda indicate a stronger deviation. Maybe @slimsag could simply create a tag for "ziggify glfw" or whatever that indicates a issue that can be closed. Then we can at a later stage (or whenever someone feels like taking the leap) easily find all these issues to implement them |
Honestly, it seems like there is a desire for this from many people. And if there's enough desire that people would want to create another library on top, it seems reasonable to me to just do it here. If people do want the true C GLFW API, they can always use both together. Maybe we just dive all-in and accept this proposal as well as #61 ? |
I should also maybe note, there will later be an application library exposed by Mach specifically for setting up WebGPU applications which will be a wrapper over GLFW, HTML5/WebAssembly, Android and iOS APIs. Not sure how much it would help people going for a Vulkan or OpenGL-only approach, though. |
The one caveat I think is truly important if these changes become accepted is that they need to be clearly documented. And the readme should warn about there being deviations in the API |
Yes, I agree with that. Seems easy enough to do though :) |
I guess my bigger worry here would be what do we do once the API has stabilized a bit, people are depending on this library and someone wants to introduce some new nicety on top? We can defer that decision until at least Zig 1.0, and I expect people will pull this dependency in via a versioning system (git submodule etc.) but it'd be nice to get as many of these proposals out of the way before we break the API for folks too much :) |
We should also do what this issue proposed for |
Yes consistency is good!
Could you clearify? Do you mean that it would be better to do these changes now, rather than later or vice versa? |
Yes exactly, better to make as many of these changes as we can now rather than later. |
I would be willing to assist if we go for these changes 😄 |
PRs welcome :D Let's go for it! |
I'll try and do a PR for this in the next few days unless someone gets to it first :) |
Fixed by #71 |
GLFW's C API uses "window hints", which aren't hugely user friendly. In Zig, we can do much better by using an "options" struct with default values. My own GLFW wrapper does this for GLFW's window creation, which makes the API much nicer in my opinion.
It could be argued this deviates too far from the C API, but at the same time it doesn't really change much - just combines a few function calls into one, making the API use Zig idioms. I think of it similarly to error handling.
Here's an example of how window creation could look using an options struct:
The text was updated successfully, but these errors were encountered: