> > Fair warning - Redesign opportunity: > > Seems that the event propagation code was amidst a change for the > > 0.3.0 release, and then not ever completed. > > By example, Scenes and Layer supposedly inherits code from > > scene.EventHandlerMixin, but that code is never executed, and anyway > > in that code the line > > scene = self.get(Scene) > > will traceback any time. ( probably wanted to be scene = > > self.get_ancestor(Scene) )
I see. Is properly implementing EventHandlerMixin as simple as fixing the above line and then calling EventHandlerMixin.add() and .remove() from the Scene, like this? +class Scene(cocosnode.CocosNode, EventHandlerMixin): + def add(self, child, z=0, name=None ): + super(Scene, self).add( child, z, name ) + + def remove(self, obj): + super(Scene, self).remove( obj ) > > > I also removed event pushing from the on_enter > > > method, since that would otherwise cause events to be registered in order > > of > > > on_enter being called. > > > What if a program wants to spawn a mouse pickable actor some time > > after the scene has been running ? > > The basic problem is that the pyglet event dispatcher stores the > > listeners in a stack, a linear structure, and we want to walk the tree > > in front to back. > > Other that implement a cocos dispatcher, when adding a handler to a > > running scene we should: > > (sorry; following) > > empty the stack > rebuild the stack > > Use case: > scene > far layer > middle layer > front layer > > after some time running, our game wants to add a new child to far layer > which should receive mouse events. > > ---------- > > I guess the responsibility to decide how to register handlers should move to > the add method: > when adding to the an offline node, it does nothing > when adding to an online node, it should call the top node to empty the > listeners stack and then rebuild (including the just added object) > That solution seems best. It solves the specific problem, instead of reimplementing EventDispatcher to use a tree structure. > Other loose ends / sub-specification for the event handling subsystem: > > + front to back order seems sensible for mouse events; it is acceptable > for > other events ? It seems fine to me for all keyboard and mouse events, at least. I wouldn't be very surprised if someone comes up with a counter-example, though. > + the automatic registration only registers for events generated by the > window; should we also register for the director events ? The only director events seem to be on_push, on_pop, and on_(cocos)_resize. Back-to-front order might make more sense there, but I'm not sure. I haven't personally done much with those events, yet. > + should only scenes and layers be allowed to receive events ? > current code allows you to register any object as listener, by example > a sprite, but you must register as listener manually Automatic event registration for all nodes would be nice, especially if handled as it is in the Layer class (i.e. with an is_event_handler class field). > + in transitions, should we block user input to the child scenes while the > transition is alive ? By default, yes. It might be nice to allow input to either the previous or next scene during the transition, but that wouldn't be a critical feature for me. > PD: about the concrete Mike problem, UI correctness: UI tends to have a lot > of little detail to care. Maybe you can use an already written ui code. > The posthttp://article.gmane.org/gmane.comp.python.cocos2d.user/1184 > gives references to use a ready made gui, highly recommended Excellent, thanks! I wasn't looking forward to writing yet another GUI, so I'll definitely check out what else is available. -- You received this message because you are subscribed to the Google Groups "cocos2d discuss" 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/cocos-discuss?hl=en.
