Thomas,
Thank you for the notes. I've made a few changes to the API I hope
you'll like:
1. I now return a MochiKit.Signal.Event object instead of mangling
the native event object. (The native event object is available as the
theParam.event property.)
2. I've changed the name of the cursor properties from pageX/Y to
theParam.cursor.x and .y.
3. I no longer "stop" by default, this is a method. So you just call
theParam.stop().
For now, I'm focused on correctness and convenience instead of
performance. That said, I ran a few simple performance tests with
synthetic events, and it looks as though we only take a 20% hit on
the event dispatch rate even after all of these calculations. I'll do
some experiments to see if I can improve this further by doing lazy
calculations in a method, so you'd call cursor().x instead of cursor.x.
I'm sorry I'm moving so slowly on all of this, but I only started
digging into heavy JavaScript this month, and still have a lot to learn.
On 23-Jan-06, at 12:56 AM, Thomas Hervé wrote:
I don't really understand your question (maybe because of my english,
sorry), but I take advantage of your post to show my comment here :
http://trac.mochikit.com/ticket/27.
To make it clear, I don't think modifying the event object is a good
thing, and is totally against MochiKit usual code. I'd prefer multiple
methods that does what I want (pointerX(event) for example, or
pointers(event) if you want to get X et Y at the same time) over your
big single _fixEvent where 80% of the job is useless in 80% of the
time.
The other problem is see is the stop of events by default (it's really
lame, you can't even access the shortcuts of your browser after), and
__listeners/__signals slots added to objects (that would be great
to do
without, and I think there's solution).
Besides, you're doing a great job in compatibility, and I hope it will
be integrated one way or another.
--
Thomas
