Thanks for the response, the observer example made the most sense to me, but the fact it was listed separately confused me a little.
I found this (http://python.cocos2d.org/doc/programming_guide/basic_concepts.html) searching for pyglet event examples. The event system near the bottom cleared up the questions for me and now I understand it, especially how it would be used in a game. One thing I find weird about the event system is the fact we push to the top (insert at index 0) instead of the bottom (append). For example, if I want to have my GUI always the first handler since it will always be the most top level over the world, I have to define everything in the game before I can push the GUI handler to the window. I can't just push a handler dynamically in the world (at a later time for example) to the window that would take key inputs, as then it would be handled before the GUI. The only other way I can see this working is if I create a custom dispatcher that replaces the window dispatcher (for the world) that is just re-dispatching the events from the window to its own listeners. I don't know if there is another way, or if that's the intended method to do it. Maybe I'm just set in a specific way, but for me its a little backwards to me. On Tuesday, July 11, 2017 at 2:37:05 AM UTC-5, Benjamin Moran wrote: > > (Current docs for reference: > http://pyglet.readthedocs.io/en/latest/programming_guide/events.html ) > > I've never done any serious UI programming myself so I'm not the best to > comment here, but I've also found this example a little obtuse. > Maybe we can come up with an alternate example, that might be a little > easier to follow. I do like the Observer example at the bottom, but maybe > we can just have one simple concrete example, without going into separate > techniques? > > I suppose the question is what's a good example? :) > There are some good (game related) ideas here: > http://gameprogrammingpatterns.com/observer.html > > > On Friday, July 7, 2017 at 6:56:37 AM UTC+9, Charles wrote: >> >> This may seem like a dumb question but trying to understand the point of >> the custom event dispatcher. Looking at the example: >> >> class ClankingWidget(pyglet.event.EventDispatcher): >> def clank(self): >> self.dispatch_event('on_clank') >> >> def click(self, clicks): >> self.dispatch_event('on_clicked', clicks) >> >> def on_clank(self): >> print 'Default clank handler.' >> >> >> ClankingWidget.register_event_type('on_clank') >> ClankingWidget.register_event_type('on_clicked') >> >> widget = ClankingWidget() >> >> @widget.event >> def on_clank(): >> pass >> >> @widget.event >> def on_clicked(clicks): >> pass >> >> def override_on_clicked(clicks): >> pass >> >> widget.push_handlers(on_clicked=override_on_clicked) >> >> >> Is this just a way to do some sort of inheritance? What is the benefit of >> going through the event system as opposed to Widget being its own class >> with its own clank or on_clank method? For instance instead of having >> on_clank at all, just have clank and any 'widgets' that need to use it will >> have their own clank method. I understand the 'publisher/subscriber' case >> where the EventDispatcher is the caller or some sort of controller, and the >> handlers are the 'observers', but not sure how in what cases this works in >> reverse. >> >> Can someone explain this in a little more detail and some example of how >> it would be used in a game? >> > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
