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

Limitations of the DragTool #90

Open
cfarrow opened this issue Feb 25, 2013 · 3 comments
Open

Limitations of the DragTool #90

cfarrow opened this issue Feb 25, 2013 · 3 comments

Comments

@cfarrow
Copy link
Contributor

cfarrow commented Feb 25, 2013

Let's discuss limitations of the DragTool. Feel free to jump on in or link to new, existing or past issues.

The purpose of this issue is to collect ideas for improving the DragTool.

@cfarrow
Copy link
Contributor Author

cfarrow commented Feb 25, 2013

Both out-of-bounds and canceling behavior go through the cancel_drag method. It is not possible to provide differing behavior for these two events without reimplementing or overloading some of the private interface. See a related discussion in #89.

@corranwebster
Copy link
Contributor

You can only have one modifier key set for initiating a drag (so no chording like Shift-Ctrl-LeftButton). See the value drag tool for an example of how to do multiple modifier keys. This would be a backwards-incompatible change, if it were pushed down into the DragTool proper.

@pberkes
Copy link
Contributor

pberkes commented Feb 25, 2013

The information about what initiated a cancel should be in the event, so sub-classes can distinguish between the two cases.

I agree that simplifying the class, and making typical behaviors accessible through parameters rather than sub-classing, should be possible.

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

No branches or pull requests

4 participants