4

I know that in order to write a GTK application, I write a bunch of code which describes what is put in the main window, then I call:

gtk_main();

Any code statements after this do not get executed.

Now let's suppose I'd like my GTK app to display something I wrote with glut, which itself contains a bunch of statements about what graphics need to be set etc. then ends with the statement:

glutMainLoop();

Anything after this is not executed.

So my problem is that either of these two statements prevents me from calling the other.

  1. Is there a way to execute a glut main loop inside a GTK widget ?
  2. Is there a way to write a code that could somehow simultaneously call both a GTK main loop and a glut main loop (but called from the main program and rendered in a separate X window, not within a widget)? I've got a feeling this could be done with "threads"...
mtvec
  • 17,846
  • 5
  • 52
  • 83
kotozna
  • 311
  • 5
  • 19
  • 1
    You should give a try to [glfw](http://www.glfw.org/): it's the perfect replacement for GLUT and will allow you to handle the main loop yourself. – Simon May 03 '12 at 03:03

2 Answers2

4

You don't. There's generally no point to it.

GLUT is a library for creating and managing OpenGL windows. GTK already has an OpenGL window in it. If you're using GTK, then there's no point in using GLUT. It's like having two vector math libraries or something.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
  • Well I have written a scientific code that produces a bunch of data. I've also written a GTK code which allows someone to enter the initial conditions for the scientific code, and I've written a code using glut which displays the output data. What I want to do is combine all 3 into one code... – kotozna May 02 '12 at 20:02
  • So I've herd that gtk doesn't guarantee widget frame updates, eg GL widgets can be put to sleep; maybe I'm being paranoid, I wanted glut and gtk to share a window so I could let both glut and gtk schedule thier draws normally for their respective duty cycles – ThorSummoner Aug 11 '18 at 05:10
3

You are running the main loops. gtk_main() runs until gtk_quit() is called.

gtk_main() at GTK.org

Runs the main loop until gtk_main_quit() is called. You can nest calls to gtk_main(). In that case gtk_main_quit() will make the innermost invocation of the main loop return.

Also, glutMainLoop() works the same way, it processes GL events forever.

glutMainLoop() at OpenGL.org

glutMainLoop() enters the GLUT event processing loop. This routine should be called at most once in a GLUT program. Once called, this routine will never return. It will call as necessary any callbacks that have been registered.

So, you you wan't both of these things to execute at the same time (I think they might interfere with each other so you might get unexpected results) then you will need to call gtk_main_iteration() from inside glut.

gtk_main_iteration() at GTK.org

Runs a single iteration of the mainloop. If no events are waiting to be processed GTK+ will block until the next event is noticed. If you don't want to block look at gtk_main_iteration_do() or check if any events are pending with gtk_events_pending() first.

Now.. GLUT doesn't have an equivalent to gtk_main_iteration() so you are going to need to register GLUT callbacks.

You could register a callback with GLUT that runs gtk_main_iteration() using glutIdleFunc(void (*func)(void)) which will run a callback for every frame - glutIdleFunc()..

Or you could give a callback to glutTimerFunc(unsigned int msecs, void (*func)(int value), value) to call and check the return value of gtk_main_iteration() every 200msec or so.

I'd probably experiment with both, glutIdleFunc() might not always get called regularly enough for good responsiveness.

It really is worth looking at driving GTK's GL support though.

IanNorton
  • 7,145
  • 2
  • 25
  • 28