-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Two #71
Conversation
Fil
commented
May 15, 2020
•
edited
Loading
edited
- 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
(rationale: don't let people install @2 in a build system that will not alert them that we have moved to ES6, only to cause trouble with a later release.)
… the new gesture gets overridden this showed in the brush transition notebook https://observablehq.com/d/a5be418e6d408119 where interrupting the "brush.move" after a first gesture would not emit the proper sourceEvent in the subsequent brushend
New version! |
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. |
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). |
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. |
Agree. I think the closure makes this fork of versor dragging a bit cleaner (removing the |
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. |
The multitouch version is https://observablehq.com/d/7a912fba32fbe641 the relevant part of the code is sending [x, y, angle] instead of [x, y]:
and it's consumed by
|
Do you think that having zoomEvent.on would make the multitouch easier? My guess is no but you wrote the code. :) |
A multitouch fork using zoomEvent.on is here https://observablehq.com/d/0d284a21aa8e4aa4 |
I vote for removing zoomEvent.on and brushEvent.on until we have evidence to believe they will be useful. |
Co-authored-by: Mike Bostock <mbostock@gmail.com>
Discussion reference: - #71 (comment) - #71 (comment)