I'm slowly figuring out how Pyglet works under the hood, and am always pleasantly surprised. The window closure problem stemmed from a misunderstanding of the semantics of has_exit and close; for example, I thought close was supposed to set has_exit to True. Now I've gotten rid of close_later altogether and just use has_exit, as I think you intended.
I was having problems with the context being destroyed earlier in development of the class, but I think it may have been because of related misconceptions. I've gotten rid of all that now. I've also switched over to Clock, works great! Anyway, it took me a while to find the right paradigm for ManagedWindow, but it's working really well now. It might be nice to see something like it in the examples directory. Thanks for the help! Brian On 7/21/07, Alex Holkner <[EMAIL PROTECTED]> wrote: > > > > On 22/07/2007, at 7:46 AM, brian.jorgensen wrote: > > > > > Now it seems I'm having an issue in interactive mode on linux. When I > > press escape or click the close box, the event loop is exiting, but > > the window continues to be displayed (though of course, it is not > > redrawn and does not respond to events). Can you think of how this > > could happen? FTR, I'm not familiar with xlib at all. When I run in > > non-interactive mode, the window is properly cleaned up, if only > > because the process dies as soon as the event loop finishes. > > Looks like you're not calling super(ManagedWindow, self).close() when > has_exit is True (i.e., after the loop closes). Alternatively, you > could override the on_close and on_key_press handlers to set > close_later rather than has_exit. > > > It may also be useful to note that I'm attempting a multithreaded use > > of Window. I need multiple threads because I need to be able to > > control the plot interactively (i.e. from the python console). It's > > working pretty well, except for this issue, which only seems to affect > > XLibWindow (haven't tried Carbon yet, though). > > The class looks really nice, BTW. A couple of comments: > > You can use pyglet.clock.Clock directly if you need more than one > clock (this will save you some code, and prevent excessive busy > waiting on fast machines). > > Why all the tests for self.context != None? Is there some problem > you're getting where the context is being deleted? > > No need for "global" statement near gl_lock. > > Cheers, > Alex. > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
