Skip to content
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

Controller shouldn't deactivate on mouseDrag #89

Open
conorrussomanno opened this issue Nov 16, 2016 · 5 comments
Open

Controller shouldn't deactivate on mouseDrag #89

conorrussomanno opened this issue Nov 16, 2016 · 5 comments
Labels

Comments

@conorrussomanno
Copy link

conorrussomanno commented Nov 16, 2016

I think controlP5 would feel much more responsive as a whole if you were able mousePress to activate a controller then move your x/y coordinates before mouseRelease, and still call the event of the button/listItem/etc. Right now, I have a number of scrollableLists and buttons, and if I press, accidentally move at all, and then release if feels like it should click, but doesn't... This would be a big fix for the overall feel of the library.

If this is already possible, please let me know!

@GoToLoop
Copy link

@sojamo
Copy link
Owner

sojamo commented Nov 16, 2016

can you give an example, a working sketch that highlights the problems you encounter?

@quarks
Copy link

quarks commented Nov 16, 2016

This comment is also based on the discussion posted by the OP in the Processing forum.

A mouse 'click' generates 3 events in this order

  1. PRESS
  2. RELEASE
  3. CLICK (provided the mouse has not moved between (1) & (2)

If the mouse moves between (1) and (2) the you get multiple DRAG events

  1. PRESS
  2. DRAG
  3. DRAG
    ...
    ?) RELEASE

The first is appropriate behaviour for a GUI button and gives the user an opportunity to cancel a button-click by moving the mouse before releasing the mouse button. The second is appropriate for a slider.

Although it should be possible to modify the GUI button behaviour so that a CLICK event is fired provided the mouse has not left the button surface before RELEASE, it would not be the expected behaviour of 99.9% of users.

In fact I don't think this is an issue with controlP5. I think that the controllers are responsive, they just don't respond in the way the OP wants.

@sojamo
Copy link
Owner

sojamo commented Nov 17, 2016

thanks @quarks for this.
@conorrussomanno you can take a look at the ControlP5callback example to customize controller actions. Like quarks already highlighted, the behavior you are describing results in a drag-action which cancels out the click-action but still triggers the release-action when the mouse is released inside. An outside release is detected as a releasedoutside-action. If this answers your question, please close the issue.

@conorrussomanno
Copy link
Author

Thanks, guys. I'll give it a try and close the issue (in addition to posting my solution) if I can fix the bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants