On Mon, Nov 22, 2010 at 12:51 PM, Claudio Canepa <[email protected]>wrote:
> > > On 22 nov, 12:15, claudio canepa <[email protected]> wrote: > > ---------- Forwarded message ---------- > > From: <[email protected]> > > Date: Tue, Nov 16, 2010 at 10:04 PM > > Subject: Issue 163 in los-cocos: Event order > > To: [email protected] > > > > Status: New > > Owner: ---- > > > > New issue 163 by mikejohnwyatt: Event orderhttp:// > code.google.com/p/los-cocos/issues/detail?id=163 > > > > What steps will reproduce the problem? > > > > 1. Create a heirarchy of event-handling layers. At least one of the > layers > > should have multiple child layers. All layers should handle the same > event > > and not return EVENT_HANDLED. > > > > Example: > > > > Scene > > BackgroundLayer (z=0) > > GuiLayer (z=1) > > AlphaButton (z=0) > > BravoButton (z=1) > > > > 2. Run the program and fire the event. > > > > What is the expected output? > > > > I expect the event handlers to be called in the following order: > > > > 1) BravoButton > > 2) AlphaButton > > 3) GuiLayer > > 4) BackgroundLayer > > > > What do you see instead? > > > > In reality, the order is like this: > > > > 1) BackgroundLayer > > 2) AlphaButton > > 3) BravoButton > > 4) GuiLayer > > > > The problem is that the event handlers are simply pushed onto the window > in > > order of the layer's children list (which is sorted with the lowest Z > values > > first). This results in the handlers being called from back-to-front, > > instead of the documented front-to-back (from > \cocos\layer\base_layers.py: > > "Events are propagated to layers (from front to back) until some layer > > catches the event and accepts it."). > > > > I need the order to be front-to-back so I can implement a basic GUI, in > > which events (like a mouse click) can be first caught by a widget (like a > > button) before being optionally passed to the background (i.e. if no > button > > was clicked). > > > Front to back order is also sensible for selecting an actor with the > mouse. > And yes, current cocos don't honor the front-to-back. > > 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 have attached a patch file to fix this issue. Basically I just > reversed > > the order of pushing child handlers onto the window in the scene and > layer's > > push_all_handlers() method. > > Reversing the order seems sensible > > > 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) ---------- 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 ? + the automatic registration only registers for events generated by the window; should we also register for the director events ? + 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 + in transitions, should we block user input to the child scenes while the transition is alive ? Comments ? Other situations to consider ? 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 post http://article.gmane.org/gmane.comp.python.cocos2d.user/1184 gives references to use a ready made gui, highly recommended -- 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.
