Eventing System

Sorry for late reply. I also think most UI events can stick inside the UI layer (@trusktr & @steveblue, reply coming soon to your awesome ideas about the UI / worker separation, thanks!). DIsclaimer: I haven’t started working on my event model yet.

I guess there are two issues here:

  1. Eventing API
  2. Kinds of events

To focus on the latter, in our model, we just need to consider what kinds of events people need and how they intend to use them, to make sure we have all cases covered. Particularly I mean what needs to leave the UI thread, and latency. e.g.

  1. Swiping, etc. It’s enough to just call setPosition() on the UI thread.
  2. Parallax or anything that depends on mouse position, probably enough to send just mouse position to components.

Keeping events on the UI layer greatly simplifies things for us and for developers, assuming it all works.

Also, no one mentioned HammerJS. I admit I haven’t used it but it seems to be the most popular library for cross platform touch. It looks like it covers everything we need (including e.g. velocity) and I think if we just put a simple wrapper around it to integrate nicely with nodes, we can benefit from this mature and popular package.

I know everyone loved GenericSync… I didn’t use it much, was the main advantage the single API for click and touch? Does HammerJS cover that? From just the front page, it’s no problem to drag / flick with my desktop mouse, and I briefly saw something about emulating multi-touch too.

@steveblue accomodating accelerometer etc would be awesome! Would be one of those wow things on mobile.