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

Remove default start trigger #114

Closed
visiongeist opened this Issue Nov 25, 2014 · 7 comments

Comments

Projects
None yet
2 participants
@visiongeist

visiongeist commented Nov 25, 2014

On touchdevices having touchstart on an element to start dragging will eventually block the scrolling capability. If the default initial event can be disabled then the application may use the current api to start on a custom event (e.g. hold)

@taye

This comment has been minimized.

Show comment
Hide comment
@taye

taye Nov 26, 2014

Owner

This is a good idea. Do you have any thoughts on what the API for doing this should be like? I think this could be good but I'm always open to suggestions:

interact(target).draggable({
  starter: <string>,
  ender: <string>,
  ...
});

starter and ender could be

  • "up", "down", "tap", "doubletap" or "hold" to start on the specified event type (I don't think that allowing "move" to be used is a good idea),
  • "default" to use the current behaviour where a down then move event starts a drag or
  • "manual" to only start when told to do so through a new Interaction#start method:
interact(target).on('hold', function (holdEvent) {
  // if the pointer that caused the hold event isn't part of an active interaction
  if (!holdEvent.interaction.interacting()) {
    // start a new drag action with the current event target
    holdEvent.interaction.start('drag', holdEvent, holdEvent.interactable, holdEvent.currentTarget);
  }
});

Then Interactable#preventDefault can be used to allow scrolling etc.

Owner

taye commented Nov 26, 2014

This is a good idea. Do you have any thoughts on what the API for doing this should be like? I think this could be good but I'm always open to suggestions:

interact(target).draggable({
  starter: <string>,
  ender: <string>,
  ...
});

starter and ender could be

  • "up", "down", "tap", "doubletap" or "hold" to start on the specified event type (I don't think that allowing "move" to be used is a good idea),
  • "default" to use the current behaviour where a down then move event starts a drag or
  • "manual" to only start when told to do so through a new Interaction#start method:
interact(target).on('hold', function (holdEvent) {
  // if the pointer that caused the hold event isn't part of an active interaction
  if (!holdEvent.interaction.interacting()) {
    // start a new drag action with the current event target
    holdEvent.interaction.start('drag', holdEvent, holdEvent.interactable, holdEvent.currentTarget);
  }
});

Then Interactable#preventDefault can be used to allow scrolling etc.

@visiongeist

This comment has been minimized.

Show comment
Hide comment
@visiongeist

visiongeist Nov 26, 2014

The question is if we want the user to control the events on this level. With all the different events bound for start and end it could be pretty complicated for the internal implementation + the developer who configures it. How about deactivating the automatic start in general. For instance

interact(target).draggable({
  autoStart: <boolean>, // default true
  ...
});

and then

interact(target).on('hold mousedown pointerdown', function (holdEvent) {
  // if the pointer that caused the hold event isn't part of an active interaction
  if (!holdEvent.interaction.interacting()) {
    // start a new drag action with the current event target
    holdEvent.interaction.start('drag', holdEvent, holdEvent.interactable, holdEvent.currentTarget);
  }
});

WDYT?

btw. could you imagine a use case for the end case?

visiongeist commented Nov 26, 2014

The question is if we want the user to control the events on this level. With all the different events bound for start and end it could be pretty complicated for the internal implementation + the developer who configures it. How about deactivating the automatic start in general. For instance

interact(target).draggable({
  autoStart: <boolean>, // default true
  ...
});

and then

interact(target).on('hold mousedown pointerdown', function (holdEvent) {
  // if the pointer that caused the hold event isn't part of an active interaction
  if (!holdEvent.interaction.interacting()) {
    // start a new drag action with the current event target
    holdEvent.interaction.start('drag', holdEvent, holdEvent.interactable, holdEvent.currentTarget);
  }
});

WDYT?

btw. could you imagine a use case for the end case?

@taye

This comment has been minimized.

Show comment
Hide comment
@taye

taye Nov 26, 2014

Owner

The question is if we want the user to control the events on this level. With all the different events bound for start and end it could be pretty complicated for the internal implementation + the developer who configures it. How about deactivating the automatic start in general.

Good point. I think it's much better this way. The only thing that I'm not sure about is whether or not manualStart: true/false would be better than autoStart: false/true :-).

btw. could you imagine a use case for the end case?

With a touchscreen, I can't think of any. With a mouse, I was thinking about starting a drag with a tap and moving while the mouse button isn't pressed then ending the drag with a second tap. Probably not a good idea though.

Owner

taye commented Nov 26, 2014

The question is if we want the user to control the events on this level. With all the different events bound for start and end it could be pretty complicated for the internal implementation + the developer who configures it. How about deactivating the automatic start in general.

Good point. I think it's much better this way. The only thing that I'm not sure about is whether or not manualStart: true/false would be better than autoStart: false/true :-).

btw. could you imagine a use case for the end case?

With a touchscreen, I can't think of any. With a mouse, I was thinking about starting a drag with a tap and moving while the mouse button isn't pressed then ending the drag with a second tap. Probably not a good idea though.

@visiongeist

This comment has been minimized.

Show comment
Hide comment
@visiongeist

visiongeist Nov 26, 2014

manualStart sounds better to me :)

visiongeist commented Nov 26, 2014

manualStart sounds better to me :)

@taye

This comment has been minimized.

Show comment
Hide comment
@taye

taye Dec 8, 2014

Owner

PR #124 is just about ready for use. There are a few small differences in Interaction#start to what I originally thought of:

  • The action is supplied with an object with a name property so that other properties of the action can be provided eg: { name: 'resize', axis: 'y' }
  • There's no event argument. The downEvent of the interaction is always used.

Let me know how it works out for you.

Owner

taye commented Dec 8, 2014

PR #124 is just about ready for use. There are a few small differences in Interaction#start to what I originally thought of:

  • The action is supplied with an object with a name property so that other properties of the action can be provided eg: { name: 'resize', axis: 'y' }
  • There's no event argument. The downEvent of the interaction is always used.

Let me know how it works out for you.

@visiongeist

This comment has been minimized.

Show comment
Hide comment
@visiongeist

visiongeist Dec 10, 2014

I haven't had a chance to look at it ... I will ping you. Thx for fixing so quickly.

visiongeist commented Dec 10, 2014

I haven't had a chance to look at it ... I will ping you. Thx for fixing so quickly.

@taye

This comment has been minimized.

Show comment
Hide comment
@taye

taye Dec 14, 2014

Owner

@visiongeist @ethanve

I'm merging #124 into master now because I'm working on a fix for #132 which would conflict with these changes. I'm fairly sure that the branch is solid.

Thanks for creating this issue. Let me know if you run into any problems or have any suggestions.

Owner

taye commented Dec 14, 2014

@visiongeist @ethanve

I'm merging #124 into master now because I'm working on a fix for #132 which would conflict with these changes. I'm fairly sure that the branch is solid.

Thanks for creating this issue. Let me know if you run into any problems or have any suggestions.

@taye taye closed this in #124 Dec 14, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment