1

I am writing a python tkinter application that interfaces with a C++ library that I am also writing. The C++ library contains a class that wraps some of GLUT's functions.

My main function (python) looks something like this:

import sys
import tkinter as tk
import myCustomCppLibrary

#This sets up the GLUT bindings.
myCustomCppLibrary.Initialize()

root = tk.Tk()
# ... some stuff

#Something in mainloop() eventually calls glutMainLoop()
root.mainloop()
myCustomCppLibrary.Finalize()
sys.exit(0)

Unfortunately, glutMainLoop blocks root.mainloop(), meaning that my tkinter GUI becomes unfunctional as soon as my GLUT window is launched.

I did try to add a std::thread object to my wrapper class but glutMainLoop appears to exit the entire process after exiting, meaning that running it in a thread is not conducive to a clean exit.

I was thinking that I could use GLUT's atexit to signal to tkinter that it needs to close and join the thread, but ideally the process would not end when I close the GLUT window (I don't think this would give a clean exit either).

Is is possible to have these two loops run concurrently, and to do so cleanly?

I would like to avoid modifying GLUT's source code.

wvn
  • 624
  • 5
  • 12

1 Answers1

2

You can't mix GLUT with other windowing frameworks. At least not without going through a lot of pain. But one has to wonder: What is there in GLUT that you must use it? With a little extra module you can create an OpenGL context within TkInter Tkinter OpenGL context in Python

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • Interesting, I will certainly look into this. I require access to the underlying opengl resources (I am binding a CUDA array to an opengl texture) so hopefully that is something I can do with this. – wvn Jul 28 '20 at 12:30
  • 1
    @wvn: … but how does that make you depend on GLUT? Answer: It doesn't! – GLUT is just some "random" framework out there. Originally created to faciliate quick-and-dirty OpenGL tinkering programs. – datenwolf Jul 28 '20 at 13:10
  • You are certainly correct that I am bound in no way to GLUT. I was using that simply because I have another application that does something similar, so I went for familiarity. My concern now is that if I run my OpenGL context through Togl that I will need to access low-level resources in my external C++/CUDA library. For someone as unfamiliar with OpenGL as I, that will be a challenge. Either way, probably worth learning. – wvn Jul 28 '20 at 18:45
  • 1
    @wvn: As far as GLUT vs. Togl goes with respect to CUDA: There is zero difference. OpenGL is pretty much a "What You See Is What You Use" API. There's no "hidden", low level stuff going on. A OpenGL context is created using a windowing system specific API (usually wrapped in a framework) and from there on, that's it. GLUT does nothing "special" to faciliate CUDA (heck development of the original GLUT ceded long before CUDA was on the horizon). – datenwolf Jul 28 '20 at 19:05
  • Having taken a second look at the source from one of my old GLUT projects it actually seems as though doing what I need will not be difficult. I recall that OpenGL is state-based so I assume that I can simply create and bind textures as long as it all happens within the same process. I think the way forward here is clear now. I appreciate the input. – wvn Jul 28 '20 at 21:40