Improve event listener/handler interface

[GregStanton]

THE REASON FOR THIS CHANGE
The previous interface caused confusion. For example, setObjectIsHovered might be interpreted as a setter for a Boolean (which it is not), rather than as a setter for a method that returns a Boolean (which it is). This problem was surfaced by pull request #9.

CRITERIA FOR THE NEW INTERFACE
The interface in this PR is intended to alleviate confusion by satisfying the following design criteria:

• flexible enough to handle a wide range of events
• intuitive enough for beginners
• consistent enough with p5

THE NEW INTERFACE
Here's the new interface:

setEventDetector(type, detector)
setEventResponder(type, responder)

• type: a string (e.g. ‘mousepressed’ and ‘mousereleased’)
• detector, responder: callback functions for the listener and handler, respectively¹

Note that the type parameter supports the exact names of p5 handlers, such as mousePressed().² When there's no corresponding event handler in p5, we'll typically match Web API names (e.g. ‘mouseover’ and ‘mouseout’), but we may choose our own names if there's a good reason to do so. This pull request also renames some internal variables using a more intuitive naming scheme that matches the new interface.

COMPARISON TO OTHER INTERFACES
The approach in this pull request is similar to the addEventListener() method of the EventTarget Web API and the .on() method of Konva.js. One major difference is that setEventDetector() and setEventResponder() are attached to a Mathemagical interaction object, rather than the ultimate event target (a drawing object).

This way, the user only needs to create a single interaction object in order to apply multiple listeners and handlers (e.g. for a draggable square, multiple listeners and handlers are used to change the cursor on mouseover and mouseout events, and also to change the position on drag events).

Footnotes

1. "Detector" and "responder" are hopefully more intuitive to beginners than "listener" and "handler." ↩

2. Since event types are passed as strings, they're all lowercase, but otherwise they have the same names as p5 event handlers when applicable. ↩

[GregStanton]

Quick note:

I used multiple-event-responders.js to test addEventResponder() and deleteEventResponder(), including the error messages that they produce.

I also used that sketch to do basic tests of the new stroke-weight features in the Square class.

[GregStanton]

TODO

Although we have more features planned (e.g. custom events and custom interaction objects), all that's left for this PR is to implement the following methods on Draggable:

deactivateDefaultResponder(type)
reactivateDefaultResponder(type)

We could do a basic test by calling these with the 'mouseover' type from multiple-event-responders-demo.js. If the deactivate method works, the cursor will no longer change to a move cursor but the stroke will still change; reactivating will restore the original behavior. Once that's done, we can do a quick code review and merge what we have.

Here's my reasoning on prioritizing deactivate/reactivate: Without this, we have no way of resetting default responders, which is something we were already able to do in the original design. (In the original design, we could also reset default detectors. However, that's a less common use case, and the planned features will provide other ways of customizing the default detectors. For example, we'll have customizable hit regions, and it will be possible to create default detectors and responders from scratch for custom events. That all may change, but for now, that's the idea.)

UPDATE

The commits below complete this TODO item. I used deactivate-default-responders-demo.js to do basic tests. We may want to do a quick code review, but otherwise this PR is ready to be merged.