Thanks much for this suggestion. I'm not sure I've correctly understood the operation "start_new_thread(lambda: __import__(<your module>), ())". By "your module" do you mean the user program which imported the module that will execute start_new_thread? It hadn't occurred to me to have A import B and B import A, though now that you describe this (if that's indeed what you mean) it makes sense. The original instance of A won't get past its initial import statement because the main loop won't return to it.
Bruce Sherwood On Sat, Jul 21, 2012 at 2:32 AM, Dieter Maurer <die...@handshake.de> wrote: > Bruce Sherwood <bruce.sherw...@gmail.com> writes: >> ... >> from visual import box, rate >> b = box() >> while True: >> rate(100) # no more than 100 iterations per second >> b.pos.x += .01 >> >> This works because a GUI environment is invoked by the visual module >> in a secondary thread (written mainly in C++, connected to Python by >> Boost). The OpenGL rendering of the box in its current position is >> driven by a 30-millisecond timer. This works fine with any environment >> other than Mac Cocoa. >> >> However, the Mac Cocoa GUI environment and interact loop are required >> to be the primary thread, so the challenge is to have the visual >> module set up the Cocoa environment, with the user's program running >> in a secondary thread. Any ideas? > > The usual approach to this situation is to invoke the user code via > a callback from the UI main loop or invoke it explicitely > after the UI system has been set up immediately before its main loop > is called. Might look somehow like this: > > main thread: > > from thread import start_new_thread > from visual import setup_gui, start_main_loop > setup_gui() # sets up the GUI subsystem > start_new_thread(lambda: __import__(<your module>), ()) > start_main_loop() -- http://mail.python.org/mailman/listinfo/python-list
