Well, if I move the code in pyglet.app.cocoa.CocoaEventLoop.__init__() to CocoaEventLoop.start() instead, then no GUI code executes until the event loop is started. (But only if shadow_window is False -- otherwise pyglet.app.base.EventLoop._legacy_setup() tries to make a window before the CocoaEventLoop.start gets called, so there's trouble... but this could easily be fixed.) For example, after the above minor change, the following works:
import pyglet pyglet.options['shadow_window']=False #without the change, the dock icon would be bouncing from the next call until the event loop is started. import pyglet.app pyglet.app.event_loop.run() However, under cocoa, the following does not work. Using carbon, it does: import pyglet pyglet.options['shadow_window']=False import pyglet.app import threading t = threading.Thread(target=pyglet.app.event_loop.run) t.setDaemon(True) t.start() Using carbon windowing, the above starts the run loop in the background, and the dock icon stops bouncing immediately (indicating that the run loop has been successfully started). Using cocoa, the dock icon keeps bouncing -- something's getting held up, but I just don't know enough cocoa to really debug this. If I instrument EventLoop.idle() to print when it runs, the above gets things started up well enough to to be regularly running idle()... but somehow the GUI never gets properly started up. (It's not just dock- icon bouncing... I have fancier tests where I try to create windows in the background, and this never quite works with Cocoa; e.g. it draws a blank white window without title bar. But the dock-bouncing is diagnostic of something not getting properly initialized, so it seems a simpler test case.) Any thoughts? On Apr 28, 3:28 pm, Zachrahan <[email protected]> wrote: > Hello all, > > First, thanks to everyone who's worked on the cocoa pyglet version. > This is really fantastic. > > A while ago, I hacked up some code to run a pyglet event loop in a > background thread, so one can have an interactive python interpreter > going at the same time as pyglet windows. This all works fine as far > as the OS and GL etc are concerned (at least on mac carbon and > windows), so long as all the GUI calls are made from the same > background thread. > > I'm having trouble getting this working with cocoa, however. (It seems > to work with pyglet 1.2 and carbon when I run in 32-bit mode though.) > Basically, it seems that, even with the "shadow_window" option off, > importing pyglet.app causes some GUI code to execute (you can tell > because an icon starts bouncing in the dock then). > > It appears to be the calls in > pyglet.app.cocoa.CocoaEventLoop.__init__() that do this, starting > with: > NSApplication.sharedApplication() > > Is it possible/safe to defer these until the event loop is started? > This is how things appear to work in carbon and on windows... > > Also, while on the topic -- I see that a lot about thread-safety has > gone into pyglet 1.2, but I'm not sure what the use-cases are for > that... does this have any impact on what I'm trying to do here? > > Thanks, > Zach -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
