That's a good question. The pyglet/event.py module is worth a quick browse over, as it has a lot of useful module documentation. It doesn't, however, mention any specific reason for the ordering. It looks like a deliberate design decision (as of course it would be easier to just append to the list instead of inserting at index 0). Maybe there's an old thread around here with more information :)
On Friday, July 14, 2017 at 4:50:15 AM UTC+9, Charles wrote: > > 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.
