create DragListener as a replacement for SimpleDragHandler

[pixelzoom]

No description provided.

[jonathanolson]

Looks like an accidental closing, @jbphet can you confirm?

[samreid]

I'm using a hack in Bending Light to get around the SimpleDragHandler issues. @jonathanolson said it is OK for now but in the future DragListener could make things much nicer.

            // HACK ALERT.  Changes the event's currentTarget.  Why didn't we need to do this with the other nodes?
            // Presumably because they were in similar coordinate frames?
            // See Scenery #131 create drag listener
            // See Scenery #218 multitouch
            // There is a precedent for this hack in SimpleDragHandler.js
            var c = event.currentTarget;
            event.currentTarget = prismNode;
            prismNode.movableDragHandler.forwardStartEvent( event );
            event.currentTarget = c;

[terracoda]

@jessegreenberg is this DragListener at all relevant to BASE and issues dev:a11y#116 dev:a11y#108?

[jessegreenberg]

No, this is not related @terracoda. phetsims/balloons-and-static-electricity#116 and phetsims/balloons-and-static-electricity#108 involve understanding how the screen reader intercepts DOM events. This issue and #218 involve handling Scenery events for various multitouch issues.

[terracoda]

@jessegreenberg thanks for the clarification.

[samreid]

Please be aware of MovableDragHandler which may have some features we want in DragListener.

[pixelzoom]

Opened in 9/10/2013, this issue was created because a replacement is needed for SimpleDragHandler. 3+ years later, I'm creating yet-another subtype of SimpleDragHandler in Unit Rates. And there are now 82 occurrences of the var SimpleDragHandler = require.

Labeling for developer meeting to check in on the status and priority of this issue.

[samreid]

SimpleDragHandler seems to be working OK to me, but I'm not sure what all of the problems with it are (aside from the workaround described above). Would be good to discuss. Though with 82+ occurrences, it seems unlikely we will be able to replace them all especially if there is an API change.

[jonathanolson]

A few problems:

1. It doesn't handle multitouch canceling (Multitouch listener canceling/interaction system #218).
2. It has mostly redundant drag and translate handlers, and does a lot of extra unneeded computation for those.
3. It has (possibly somewhat unused) code that is meant to listen to ancestors being transformed, so that it can keep the dragged node at the same position (due it its use as an example).
4. Its Trail parameter given to listeners is buggy (Ruler movement is not true on extra small and extra large resolutions beers-law-lab#197)
5. The above currentTarget issues.
6. Long-term, having it reuse down-up logic instead of duplicating things would be clean and helpful.
7. Requires subtypes such as MovableDragHandler due to the complexity of overriding behavior.

[jonathanolson]

Though with 82+ occurrences, it seems unlikely we will be able to replace them all especially if there is an API change.

I wouldn't imagine initial replacement, but would just have an improved input system that would handle our canceling and interaction problems from #218. Sims could be migrated at whatever schedule potentially. Thus is the cost of delaying this long.

[samreid]

@ariel-phet suggested @jonathanolson could work on this after Proportion Playground.

[pixelzoom]

From #218 (comment):

SimpleDragHandler may need an addition cancel option, which is called when a drag is cancelled. In practice, what I need to do when a drag is cancelled is (sometimes? usually?) different from what I need to do when a drag ends normally.

[jonathanolson]

There are also actual "cancel" Scenery events that happen when a touch gesture is interrupted (say the user adds another finger or two and it triggers an app switch).

We mostly don't handle those specifically, and map both "up" and "cancel" to "endDrag", but DragListener should definitely support more of a "cancel" behavior.

[jonathanolson]

This is one of the top things on my list, and I'll be working on it over the next week or two. Removing developer meeting tag unless there is something else to discuss.

[jonathanolson]

For the core PressListener/DragListener/FireListener, I've done cleanup, design improvements and resolved almost all TODOs.

A few remaining questions:

• FireListener would have been ButtonListener (but we already have something named that). Is FireListener an OK permanent name?
• DragListener should be able to take drag bounds as either a constant {Bounds2} or Property {Property.<Bounds2>}. Currently it has dragBounds and dragBoundsProperty options (which are mutually exclusive). Should we combine this into one option?

@jbphet, I believe it is ready to look into integrating this more into sun components. Can we discuss this sometime?

[jbphet]

How about during core hours on Monday, 3/5/2018?

[jonathanolson]

How about during core hours on Monday, 3/5/2018?

Sounds good, I'll be available.

[pixelzoom]

4/26/18 dev meeting, noted while discussing phetsims/capacitor-lab-basics#214.

DragListener is ready for general use, will make fixes and improvements as needed.

Re remaining questions in #131 (comment)...

• FireListener is great.
• dragBoundsProperty only

[jonathanolson]

I'll move to dragBoundsProperty only, and will investigate attach:true on SimpleDragHandler.

[jessegreenberg]

@jonathanolson in a slack thread when queried about the usage of DragListener you said

Jonathan Olson replied:
I’m planning on updating usages if I break the API. And don’t hold off, just inform me.

I am going to start using DragListener in energy-skate-park.

[jbphet]

@jonathanolson and I just reviewed the button code in sun, and the PressListener is being used, so it appears that no more work is needed for the buttons that is related to this issue.

[jonathanolson]

I've handled all of the review items that were mentioned (or promoted others to issues). @ariel-phet , should this have more code review done, or can this be closed?