glfw: Friendlier window creation

silversquirl commented

2021-11-08 16:53:41 +00:00

(Migrated from github.com)

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,
});

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](https://github.com/silversquirl/glfz/blob/main/types.zig#L16) 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: ```zig const window = try glfw.Window.create(640, 480, "Hello, mach-glfw!", .{ .monitor = monitor, .context_version_major = 4, .context_version_minor = 5, .opengl_profile = .core, }); ```

👍 4

InKryption commented

2021-11-08 16:57:26 +00:00

(Migrated from github.com)

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.

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.

👍 1

Avokadoen commented

2021-11-08 22:09:39 +00:00

(Migrated from github.com)

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

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

emidoots commented

2021-11-08 22:12:36 +00:00

(Migrated from github.com)

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 ?

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 ?

emidoots commented

2021-11-08 22:14:46 +00:00

(Migrated from github.com)

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 commented

2021-11-08 22:15:41 +00:00

(Migrated from github.com)

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

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

emidoots commented

2021-11-08 22:16:21 +00:00

(Migrated from github.com)

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

👍 1

emidoots commented

2021-11-08 22:17:43 +00:00

(Migrated from github.com)

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

emidoots commented

2021-11-08 22:19:12 +00:00

(Migrated from github.com)

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)

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 commented

2021-11-08 22:21:48 +00:00

(Migrated from github.com)

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?

> > > 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?

emidoots commented

2021-11-08 22:22:37 +00:00

(Migrated from github.com)

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

👍 2

Avokadoen commented

2021-11-08 22:27:08 +00:00

(Migrated from github.com)

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