Closed rangera closed 11 years ago
hallister
commented
11 years ago http://stackoverflow.com/questions/10934787/gtk-window-capture-vpython-opengl-application
It seems to work but it isn't pretty.
This is at the bottom of the VPython page: "Write to Bruce_Sherwood@ncsu.edu if you don't find what you need, or to tell us how you are using VPython." Worth a shot I suppose lol.
rangera
commented
11 years ago Yes, I am actually on the current boards for this group, on google groups. The problem is that here they are talking about running them concurrently, not within each other. I already have a working version of this, and in fact this is what I ran in class for the demo, simply using threads. This isn't a problem, and I apparently understand it better than some of those users, because both threads can access the same shared variables, it's really easy to have them communicate.
The problem is having the window inside of another window, so that you have one root window. From talking with Sean, I think our thoughts are to allow us to do what we want, we are going to edit the source code, build it from our edited source, and use our own custom version of vpython. This will allow us to grab the window handle, to allow for better gtk/gui integration, and will also allow for Sean, who is familiar with OpenGL (which vpython is wrapped around) to apply different textures and UV mappings and whatnot, basically allowing for the use of the high level stuff of vpython, but also accessing the low level stuff behind it, to allow for customization and injection of our own stuff.
Basically there is a window handle in the display class defined in cvisual.hpp, that is listed under private, and we will push it into public. Or, I suppose, using better coding practice, probably introduce public methods (getHandle()) that return it.
thom5468
commented
11 years ago Since client team has decided to use pygame, this issue is being closed.
https://github.com/vpython/visual/tree/master/include
is the open source for vpython. In there, under both win32 and mac, there is a cvisual.hpp file that defines the display class for each OS. There is a window reference in private, and other OS type of stuff. This has the potential for us to modify the source, rebuild it from source, and then have an accessible window handle for use in whatever other GUI thing we do. I however am not familiar with window handling as much, so if anybody who is could take a look at this and see what you think.