Update GLFW 3.3 source code (2019/11/25) #261
Conversation
| @@ -816,7 +815,7 @@ static GLFWbool createNativeWindow(_GLFWwindow* window, | |||
| [window->ns.object setLevel:NSMainMenuWindowLevel + 1]; | |||
| else | |||
| { | |||
| [window->ns.object center]; | |||
| [(NSWindow*) window->ns.object center]; | |||
There was a problem hiding this comment.
The line that was causing the warning.
|
This change includes not only suppressing the warnings but also other fixes. IMHO only suppressing the warning should be fine, but perhaps do you want to track GLFW version with GLFW_C_REVISION.txt? |
|
No I just want to keep go-gl/glfw/v3.3 updated with glfw/stable-3.3. |
This is what I meant :-) So you don't want to cherry-pick a specific change, right? As 3.4 is still unstable, I think cherry-picking an obvious change would make sense. What do you think? |
|
Sorry, I got confused. I did not get that cherry-picking will mean the commit id in GLFW_C_REVISION.txt will diverge. I really think that the commit id in GLFW_C_REVISION.txt should exactly reflect what's version of glfw we use. 3.4 isn't stable, and we aren't using code from 3.4. The question of potential cherry-picking from 3.4 is not relevant for now. |
pwaller
changed the title
|
I agree with @pchampio and don't see why we shouldn't bring in all of the fixes on the stable branch, for now. Perhaps if we take option (B) in my tagging straw man proposals, then we could update go-gl/glfw@master to the 3.3 stable branch as frequently as someone requests it. Users who desire a specific tested version of the go bindings can pin a specific go-gl/glfw hash, or use |
|
Ah, I was misunderstanding. I didn't know there was 3.3-stable branch. Then that makes sense :-) |
fixes: #260