3 ms·
GUI toolkits certainly allow for containers to act on events before their children. For example sendEvent: and hitTest: in Cocoa. The web's event handling is c
by ridiculous_fish 7y ago
GUI toolkits certainly allow for containers to act on events before their children. For example sendEvent: and hitTest: in Cocoa.
The web's event handling is comparatively clumsy. It is cast in terms of "listeners" which are unable to directly control the event routing. Instead it exposes fixed, ad-hoc levers: stopPropagation, stopImmediatePropagation, preventDefault, etc. And because there's no good place to put these methods, they have to go on the event itself, which means that events are mutable (!).
- c-smile 7y ago"sendEvent: and hitTest: in Cocoa" That is cooperative event propagation. Means it works only when widget cooperates by itself - designed to be embeddable and expandable - so it notifies its container about events inside. Example: try to catch right mouse button click on NSButton instance. Good luck with this. "clumsy" I wouldn't say so. I am doing UIs professionally quite a long time and can prove that WWW's Event/Sinking event propagation + ability to subscribe to event by JS closures is the most flexible schema so far. It is a functional superset of events handling architectures of Windows and any toolkit there, MacOS/Cocoa, GTK and QT.