On Jul 15, 9:22 pm, David Eyk <[email protected]> wrote:
> 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. :)
I figured it out, at least for the carbon EventLoop. Commenting out
the following section stops pyglet from intercepting keyboard events,
but allows the audio to work:
if carbon.ReceiveNextEvent(0, None, ctypes.c_double(timeout),
True, ctypes.byref(e)) == 0:
carbon.SendEventToEventTarget(e, event_dispatcher)
carbon.ReleaseEvent(e)
timed_out = False
else:
timed_out = True
I just noticed that the EventLoop is structured differently in the
latest svn (r2448). My hack is from an older pyglet.app (which uses
the "run" method implementation), but it appears to be working just
fine. A similar hack to the "step" method should have the same effect.
Is anyone familiar with the win32 and xlib implementations able to
suggest similar emendations? I don't have the environments to test
these at the moment.
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
-~----------~----~----~----~------~----~------~--~---
