adamlwgriffiths / cyglfw3

Cython bindings for GLFW3
Other
20 stars 6 forks source link

Initializing changes the current working directory #21

Closed ngoldbaum closed 8 years ago

ngoldbaum commented 8 years ago

I have cyglfw3 3.1.0.2 installed on top of glfw3 3.1.2 on my Mac. I installed glfw3 via homebrew and cyglfw3 via pip.

When I run this test script:

import cyglfw3 as glfw
import os
print os.getcwd()
glfw.Init()
print os.getcwd()

I get the following output:

/Users/goldbaum/Documents/test
/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/Resources

So somehow, glfw is changing the current working directory of my python process.

ngoldbaum commented 8 years ago

This ancient bug in pyopengl might be relevant: https://sourceforge.net/p/pyopengl/mailman/message/1848157/

adamlwgriffiths commented 8 years ago

I'm afraid this is out of my control. I simply map GLFW to Python. You could try raising an issue on the GLFW repository.

ngoldbaum commented 8 years ago

So it looks like this is caused by https://github.com/glfw/glfw/issues/174 - it's actually a feature in the glfw library that it changes the working directory on initialization.

However, I don't think it makes a lot of sense for cyglfw to use this feature, and you should probably add some code to wrap glfwinit so that the working directory is restored.

See also https://github.com/FlorianRhiem/pyGLFW/issues/1 and https://github.com/vispy/vispy/issues/659.

adamlwgriffiths commented 8 years ago

I understand the sentiment. But deviating from GLFW's logic would introduce more confusion. GLFW and CyGLFW would start doing different things and CyGLFW would no longer be a GLFW wrapper. Although it's strange logic, the better method is to just add a CWD after GLFW init in your own code.