Two

[Fil]

• fix the sourceEvent: event situation
• the event in the emitter/gesture must be refreshed
• when cancelling, the event is undefined
• multitouch (drag a rectangle with two fingers) https://observablehq.com/d/2553f0eff99e5957

[Fil]

New version!

[mbostock]

This PR adds brushEvent.on so that you can register event listeners for the duration of a brush gesture, as d3-drag does. (I see you implemented that for d3-zoom, too.) What is the motivation for adding this functionality? I feel like it was needed for d3-drag because you can drag different things, but it’s overkill for d3-brush and d3-zoom because there’s only one “thing” (i.e., no per-gesture subject) that you’re interacting with. But I haven’t thought about this very much, so this is just an instinctual reaction.

[Fil]

brushEvent.on

This was for consistency of the API and of the code base.

First, I'm not sure these derived events are ever necessary, even in d3-drag (or, we should have a more purposeful example than https://github.com/d3/d3-drag#event_on ). But it seems that it can give cleaner code, in particular if we want to create utilities like versor dragging that are a bit complex and might be applied on drag.start, or if we want to adapt the gesture to what is being manipulated.

For d3-brush I don't have a credible use case in mind. Still, I'm a bit confused by the “only one thing” argument. For a counter-example we have https://observablehq.com/@d3/brushable-scatterplot-matrix (which doesn't need brushEvent.on, but could use the same closure logic as in https://github.com/d3/d3-drag#event_on ).

For d3-zoom, I think its API should be as close as possible to d3-drag's: in fact we can use zoom as an (almost) drop-in replacement for drag, for example to manipulate a bunch of pictures (https://observablehq.com/d/8de812d302552f34).

[mbostock]

I guess what I’m saying is that I don’t have a great justification for dragEvent.on, either, so I question whether it’s worth copying that to the other modules if it just makes the code more complicated.

[Fil]

Agree. I think the closure makes this fork of versor dragging a bit cleaner (removing the globals reusable variables r0, p0). Is it compelling enough? If not let's remove it everywhere.

[mbostock]

Does that dragging-with-attitude notebook handle multitouch? I can’t really tell by looking at the code and I’m not on a touch device.

[Fil]

The multitouch version is https://observablehq.com/d/7a912fba32fbe641

the relevant part of the code is sending [x, y, angle] instead of [x, y]:

    return tl > 1
      ? [
          d3.mean(t, p => p[0]),
          d3.mean(t, p => p[1]),
          Math.atan2(t[1][1] - t[0][1], t[1][0] - t[0][0])
        ]
      : t[0];

and it's consumed by

  if (pt[2]) {
      a = attitude()
        .axis(projection.rotate([0, 0]).invert(pt))
        .angle(-(pt[2] - a0) * (180 / Math.PI))
        .compose(a);
    }

[mbostock]

Do you think that having zoomEvent.on would make the multitouch easier? My guess is no but you wrote the code. :)

[Fil]

A multitouch fork using zoomEvent.on is here https://observablehq.com/d/0d284a21aa8e4aa4
I'd say the difficulty is exactly the same.

[mbostock]

I vote for removing zoomEvent.on and brushEvent.on until we have evidence to believe they will be useful.