Skip to content
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

Closed
silversquirl opened this issue Nov 8, 2021 · 14 comments · Fixed by #71
Closed

glfw: Friendlier window creation #65

silversquirl opened this issue Nov 8, 2021 · 14 comments · Fixed by #71

Comments

@silversquirl
Copy link
Contributor

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:

const window = try glfw.Window.create(640, 480, "Hello, mach-glfw!", .{
    .monitor = monitor,
    .context_version_major = 4,
    .context_version_minor = 5,
    .opengl_profile = .core,
});
@InKryption
Copy link
Contributor

I think this ties in nicely to what #61 is trying to accomplish, by removing the redundancy of access to glfw.Window.hint after window creation.

@Avokadoen
Copy link
Contributor

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

@slimsag
Copy link
Member

slimsag commented Nov 8, 2021

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 ?

@slimsag
Copy link
Member

slimsag commented Nov 8, 2021

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.

@Avokadoen
Copy link
Contributor

Avokadoen commented Nov 8, 2021

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

@slimsag
Copy link
Member

slimsag commented Nov 8, 2021

Yes, I agree with that. Seems easy enough to do though :)

@slimsag
Copy link
Member

slimsag commented Nov 8, 2021

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 :)

@slimsag
Copy link
Member

slimsag commented Nov 8, 2021

We should also do what this issue proposed for glfw.Init, as there are init hints for GLFW (and potentially one other type of hint? I forget off the top of my head)

@Avokadoen
Copy link
Contributor

Avokadoen commented Nov 8, 2021

We should also do what this issue proposed for glfw.Init, as there are init hints for GLFW (and potentially one other type of hint? I forget off the top of my head)

Yes consistency is good!

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, ...

Could you clearify? Do you mean that it would be better to do these changes now, rather than later or vice versa?

@slimsag
Copy link
Member

slimsag commented Nov 8, 2021

Yes exactly, better to make as many of these changes as we can now rather than later.

@Avokadoen
Copy link
Contributor

Avokadoen commented Nov 8, 2021

I would be willing to assist if we go for these changes 😄

@slimsag
Copy link
Member

slimsag commented Nov 8, 2021

PRs welcome :D Let's go for it!

@silversquirl
Copy link
Contributor Author

I'll try and do a PR for this in the next few days unless someone gets to it first :)

@slimsag slimsag changed the title Friendlier GLFW window creation glfw: Friendlier window creation Nov 15, 2021
@slimsag
Copy link
Member

slimsag commented Nov 16, 2021

Fixed by #71

@slimsag slimsag closed this as completed Nov 16, 2021
@slimsag slimsag added this to the Mach 0.2 milestone Jul 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants