glfw: Window hints rework

[InKryption]

I took a different approach to the one used for initialization hints, because I realized that it would probably a lot of overhead to call Window.hint for every possible hint, compared to how status quo allows one to avoid that overhead; as well, it would probably be a lot harder to maintain, given that, unlike InitHint, window initialization hints are of more types than just booleans.
This approach is (quite a bit) more verbose, but avoids the overhead, and probably makes it easier to maintain.

Also, I found that context_revision and context_no_error are listed in Window.Hint, but are not listed as hints in the docs, only as attributes; I commented them out to make what I have pass tests - is this intentional and I'm missing something, or is this the result of some mishap?

Edit: it should also be noted that unlike the change made to initialization hints, I didn't completely re-use the in-place API, because I ran into some issues regarding the type-inference in the Window.hint function, so you'll see I ended up re-implementing the code for Window.hint in HintValue.set (where HintValue is a tagged union, with a tag type of Hint).

Edit: as pointed out by @silversquirl, there isn't actually a lot of overhead involved in the struct approach, so now the union slice is no more. Now just to address the other components of this problem, such as Window.hint, which seems to have some some type inference issues which caused compilation to fail under this new model. Should we try and rework it, or discard it in favor of Hints.set (private function)?

Edit: Closes #65

• By selecting this checkbox, I agree to license my contributions to this project under the license(s) described in the LICENSE file, and I have the right to do so or have received permission to do so by an employer or client I am producing work for whom has this right.

[silversquirl]

it would probably a lot of overhead to call Window.hint for every possible hint

I had this thought initially too, but if you look at the GLFW source, it's probably about the same as calling glfwDefaultWindowHints. I'd say have a hints struct with default values, and just set all of them unconditionally.

If you do want to avoid setting hints that don't need changed though, I'd still recommend going the struct route, and just check if the value is different than the default. This is easy to do by just looping over std.meta.fields, since the typeinfo gives you default values.

A struct results in a nicer API than an array of hints - the latter still feels very much like a C API, not a Zig one.

[InKryption]

@silversquirl Good point. I don't know why I didn't actually check the source; guess that's what I get for starting this on my laptop at a café. And I guess that's also why I made this a draft.

[InKryption]

@silversquirl Do you have any thoughts on what to do with the currently unused Window.hint function?

[silversquirl]

Either move the type conversion logic in set into it, or delete it. Not much point in keeping it if it's not used

[InKryption]

Excuse my fumbling with git, trying to make the history not look messy.

[slimsag]

Thanks for all your work on this! It'll probably be a few days before I have a chance to review (at handmade Seattle and then to a wedding) so apologies for the delayed review!

[InKryption]

I had an idea to maybe add a test that compares the attribute values of a window created with Window.from(c.glfwCreateWindow(...)), to the attribute values of a window created with Window.create(...) (in that order), to check that, for any attribute whose value is initialized via Window.Hints.set, its value is the same as what would be set by GLFW itself (maybe excluding context_no_error). This wouldn't be full-coverage, but it would be something. Thoughts?

[slimsag]

@InKryption regarding:

I had an idea to maybe add a test that compares the attribute values of a window

This sounds like an obvious win to me, so yes, please do! I won't block this PR on this, please send another PR for it if I merge before you get to it.

One thing to be mindful of: if we want the test to pass on any OS, be sure to choose hints that work on all OS/platforms.

[InKryption]

@slimsag Roger roger, I'll set this as ready for merging then, in the absence of any notes you may have.

[slimsag]

Looks really great, thanks for sending this. Once my comments are addressed and tests pass I'll merge. Feel free to send the test in this PR or a separate one, whichever you prefer.

[slimsag]

Looks good to me, let me know when you're finished and I'll merge. I will need to squash merge due to non-linear history, unless you want to rebase everything (I'm happy either way)

[slimsag]

LGTM, thanks a ton again!

[InKryption]

Closes #65