-
Notifications
You must be signed in to change notification settings - Fork 32
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.SetWindowUserPointer/GLFW.GetWindowUserPointer #206
Comments
Sure, as long as it doesn't mess up callbacks or make them slow. I imagine the way to do it is nest the callbacks and optional application pointer into an object, and the pointer to that parent object is what gets attached to the GLFW window. |
Thanks, that was the exact approach I had in mind. I'll give it a try. |
It turns out I don't need these functions after all. I am now using the following technique:
where |
I would like to be able to have access to
glfwSetWindowUserPointer
andglfwGetWindowUserPointer
to avoid having to access a global, variable that contains the application context, from my callback functions. Unfortunately these functions have been appropriated the GLFW package as a way to keep track of a window's registered callbacks.Is there any interest in a PR that supports the
GLFW.SetWindowUserPointer
/GLFW.GetWindowUserPointer
APIs?The text was updated successfully, but these errors were encountered: