glfw: Window hints get reverted to default after window creation and cannot be set

[prime31]

Once a window is created the GLFW wrapper resets all the hints to default. There is no public API available to set a hint so now we are stuck in a state where we can't work with hints at all. The README states that hint is a public method but it is not.

Methods, e.g. my_window.hint(...) instead of glfwWindowHint(my_window, ...)

Possible fixes:

• make window.hint public
• dont keep resetting default hints after windows are created
• expose as public c so that we can override and call raw GLFW methods ourselves when necessary

[emidoots]

You're correct the README is out of date. The idea is that you pass a struct to createWindow with the hints, it sets them for you, and resets to defaults after the fact.

Is this approach problematic for interior with other C code, or are you having trouble finding the struct where window hints get passed in?

[prime31]

The issue here is the resetting of the defaults. Once I set a hint I wouldn't expect it to get unset without me specifically requesting it. I came across the issue when adding Dear ImGui to my project. I set some hints and then Dear ImGui would create a window with glfwCreateWindowSurface and it would fail assertions in vulkan.c due to the GLFW_CLIENT_API hint being reset:

    if (window->context.client != GLFW_NO_API)
    {
        _glfwInputError(GLFW_INVALID_VALUE,
                        "Vulkan: Window surface creation requires the window to have the client API set to GLFW_NO_API");
        return VK_ERROR_NATIVE_WINDOW_IN_USE_KHR;
    }
    ```

[emidoots]

Aha! Okay, now I understand. So glfwCreateWindowSurface internally relies on window hints. I did not realize this.

The idea with hints being passed as a struct to glfw.Window.create is that it becomes stateless: you pass in the desired state, we ensure it's that, then we wipe the state away afterwards (just because that seemed clean)

But I see now that, actually, you sometimes need those window hints to be retained for longer periods of time.

In this case, I think that your suggestion of "don't reset hints after window creation" sounds good to me (in addition to exposing a method to reset them) - this way we keep the stateless aspect of glfw.Window.create on it's own, and just leave the window hints in a "dirty" state.

[prime31]

That sounds perfecto!