On Jul 14, 11:51 pm, Richard Jones <[email protected]> wrote: > Actually they probably are still going through but Python's threading > model might be killing you.
I'm not actually using threads, only Stackless tasklets, which are not multithreaded. > To demonstrate, the following program works without a window: [...] > but will only die from a control-C when the hello() function is fired > (usually straight afterwards). The keys are getting through, but only to pyglet. I integrated your example into my main loop. Ctrl-C is the only key that gets "through" to have any effect (but I'm fairly certain it's having effect only in the pyglet-controlled code). On the plus side, the audio *does* work, which is much nicer than before. :) My hypothesis is that pyglet is intercepting any system events associated with its process somewhere inside the EventLoop code (http://pyglet.org/doc/api/pyglet.app.EventLoop-class.html) before Urwid's get_input (http://excess.org/urwid/reference.html#Screen- get_input) ever receives keycodes from the terminal. Does this make any sense? For instance, inside pyglet.app.carbon, commenting out the event- related code inside of CarbonEventLoop.run (basically all the code inside the loop) results in keycodes reaching Urwid. Of course, then the audio doesn't work. :) As I mentioned, I'm using a hacked EventLoop (so far, it just cedes control to the Stackless scheduler after each iteration), so I can hack it further, but I don't know what to make of the platform- specific ctypes code. Thanks, David --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
