Re: Feature request for EventDispatcher stack push/pop

36 views
Skip to first unread message

Nathan

unread,
Sep 4, 2012, 1:24:50 AM9/4/12
to pyglet...@googlegroups.com
On Sat, Sep 1, 2012 at 6:15 PM, darkfeline <cyber...@gmail.com> wrote:
Hi everyone!

This is my first time here so I apologize in advance if I break some rules.

I've been using pyglet for a while and I've found the EventDispatcher's push_handlers() and pop_handlers() implementation very inflexible.  Very often I want to add handlers between others in the stack, and likewise remove some in the middle of the stack.  One particular use-case is for example having sprites or other game objects which need to receive events but are created and deleted during the lifetime of the game, but there are many others (scene management is another) which can benefit greatly from this.

The change is as simple as going from:
    def push_handlers(self, *args, **kwargs):
to
    def push_handlers(self, index, *args, **kwargs):
and similarly for pop_handlers().  I realize as an API change this may be unfavorable, in which case new method names can be made (e.g. push_handlers_at()).  This is a very small change (Only 4 lines need to be changed, or slightly more added with the new method name implementation) but a huge increase in flexibility in pyglet's event system.

What are everyone's thoughts on this matter?

It sounds like you either have very complex needs, in which case you should probably just write your own functions to manipulate the stacks yourself, or your normal needs are suffering from an abnormally complex implementation.  :-)  Just my opinion -- and I'm just another pyglet user.  Every time I've found myself wishing for similar modifications to pyglet's event design, I soon found that conforming to the existing design forced me to improve my own code's structure quite a bit.

By the way, you can already remove handler(s) from the middle of the stack, providing you know exactly what callable was pushed onto it:


~ Nathan

darkfeline

unread,
Sep 4, 2012, 2:33:45 PM9/4/12
to pyglet...@googlegroups.com


On Tuesday, September 4, 2012 1:24:51 AM UTC-4, Nathan wrote:
By the way, you can already remove handler(s) from the middle of the stack, providing you know exactly what callable was pushed onto it:


This is not *quite* the same, since it leaves the frame, and you now have an empty frame you have to keep track of and double-pop later
 
Every time I've found myself wishing for similar modifications to pyglet's event design, I soon found that conforming to the existing design forced me to improve my own code's structure quite a bit.

I do feel like I'm getting hit by this the more I think about it. It may be that I'm using pyglet's event system in a way it wasn't intended, or to a degree it wasn't intended.

Nathan

unread,
Sep 4, 2012, 3:57:16 PM9/4/12
to pyglet...@googlegroups.com
On Tue, Sep 4, 2012 at 12:33 PM, darkfeline <cyber...@gmail.com> wrote:


On Tuesday, September 4, 2012 1:24:51 AM UTC-4, Nathan wrote:
By the way, you can already remove handler(s) from the middle of the stack, providing you know exactly what callable was pushed onto it:


This is not *quite* the same, since it leaves the frame, and you now have an empty frame you have to keep track of and double-pop later

"remove_handlers" (plural) claims to remove the frame as well, if it's empty.


~ Nathan 

darkfeline

unread,
Sep 4, 2012, 10:31:07 PM9/4/12
to pyglet...@googlegroups.com
On Tuesday, September 4, 2012 3:57:18 PM UTC-4, Nathan wrote:

"remove_handlers" (plural) claims to remove the frame as well, if it's empty.


~ Nathan 

Ah, that's definitely a critical reading failure on my part...  A closer read indicates that this indeed does what I was asking for.  Obviously, long hours of coding does nothing for rational thought or sanity.  *awkward bow, exit stage right*

Nathan

unread,
Sep 4, 2012, 11:20:47 PM9/4/12
to pyglet...@googlegroups.com
On Tue, Sep 4, 2012 at 8:31 PM, darkfeline <cyber...@gmail.com> wrote:
Ah, that's definitely a critical reading failure on my part...  A closer read indicates that this indeed does what I was asking for.  Obviously, long hours of coding does nothing for rational thought or sanity.  *awkward bow, exit stage right*

Hehe, good show.

~ Nathan
Reply all
Reply to author
Forward
0 new messages