You are wrong. All recents major ligthweighted frameworks support "events bubbling" (where events are passed from child to parent, as opposed to "events capturing" or "trickling", where event is passed from parent to child). Flutter for example takes this approch (events are dispached by bubbling). The reason for that is that you may pay a really small performance price and events handling may be a bit more complicated internally, but the advantages for the developper are worth it. Indeed, when a user interact with your app, he naturally expects to interact with the element that is closest to him (= with the highest z-order). So if, in your app, you have a button over a lightweighted interactive map where you can add a marker on tap for example, the user naturally expect a tap on the button to trigger that button action and not to add a marker below that button on the map... With events bubbling, handeling this type of common use cases is straightforward. As for having "one point where you can override the pointer behavior for everyone", with the bubbling approch, you just have to add a transparent component over all the others you want to override the pointer behavior for. As this transparent component covers all your other components (or just a specific zone of your screen if you want to), it would be called first durring the bubbling events dispatch phase so you can override the pointer behaviour from here... But in some edge cases, it is true that events capturing might be a lighter approach (if you have a really complex components structure, events bubbling might affect your performances on low-end devices, even if I doubt it would be perceptible...). For this reason, most frameworks actually chose to use an hybrid approach. This is the case for example for flash AS3 (https://www.adobe.com/devnet/actionscript/articles/event_handling_as3.html) or HTML/javascript since the WC3 spécifications (http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-flow-basic) (old versions of internet explorer (<9) only supported events bubbling). This is the approach that I prefer and that I intend to implement into my CN1 Fork (and that you should probably implement into CN1). In this approach, there is first a Capturing phase followed by a Bubbling phase. So each component actually receive the event twice. How I see it implemented into CN1: - during the capturing phase, the event object stores the components it pass through and call them in reverse order during the bubbling phase - an event can have two states that are passed as arguments to the events listeners (or that can be called as event object methods isCapturing() or isBubbling()) so that a component event listener knows if it has to treat this event or to ignore it (as, by default, it might receive it twice, once on each phase) - events can be consumed (in wich case they immediatly stop capturing and bubbling), stopCapturing (they would still go down (from parent to child) the components list to be able to perform the bubbling phase but won't call components event listeners during this capturing phase) or stopBubbling (they would stop the bubbling phase) and every of these methods (with their startCapturing() and startBubbling() counterpart) can be called at any point during the event propagation (for example if you call stopBubbling() from inside an event listener during the capturing phase, the capturing phase would continue and the event propagation would stop when it reach the start of the bubbling phase (unless startBubbling() has been called in the meantime)).
Bytheway, you didn't answer my question on the first post on how to prevent, with the current CN1 implementation, a pointer event on a screen zone where a button B1 covers another larger button B2 to trigger B2 action for example...? On Friday, September 21, 2018 at 6:52:52 AM UTC+2, Shai Almog wrote: > No. All lightweight frameworks start from the root frame or parent. > > This is the most efficient and most sensible way to do this in a > lightweight framework. You might be thinking of a heavyweight framework > where the components are outside of the control of the framework and thus > they are responsible for handling their own events. But if you look at the > OS implementation and other lightweight frameworks you'll see that our > implementation is how things actually work because it's the one that makes > sense. > > Here's why: > > - You have one point where you can override the pointer behavior for > everyone - the form this is very useful > - You don't pay the cost of going through all the components to process > the event logic if you do this > > Notice that the OS doesn't know about our components it just sends a > pointer event. "Someone" needs to find the component to process, that code > is in Form. If you override pointer handling there you effectively save us > the cost of walking the component hierarchy to find the right child for the > event at the given location. > > This is a far more powerful and consistent approach, one of the problems > with heavyweight frameworks is the inconsistent event dispatch behavior > which they try to normalize from the component level. > -- You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/codenameone-discussions. To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/804590b0-5068-4353-b7ee-27fc9e3262dd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
