prevent item mouse events from bubbling to canvas

[stacey]

Is there a nice clean method for preventing item level mouse events
from also firing on the canvas?

As an example:

var circle = new Path.Circle(new Point(200,100), 100);
circle.fillColor = '#000';

circle.onMouseDrag = onCircleMouseDrag;


function onMouseDrag(event) {
console.log("onMouseDrag");
}

function onCircleMouseDrag(event) {
console.log("onCircleMouseDrag");
}


In this onCircleMouseDrag event handler, I'd like to say this event
has been handled and doesn't need to be fired for the canvas. The
only solution I have found thus far is to use a global flag to
indicate this. I tried event.stop() and event.stopPropagation() and
event.preventDefault() and even return false but none seem to have an
effect. If possible, this would be a great feature.

[stacey]

This works, but it's not ideal:

var circle = new Path.Circle(new Point(200,100), 100);
circle.fillColor = '#000';
circle.onMouseDrag = onCircleMouseDrag;

var itemDragging = false;

function onMouseUp(event) {
itemDragging = false;
}

function onMouseDrag(event) {
if (itemDragging) return;

console.log("onMouseDrag");
}

function onCircleMouseDrag(event) {

itemDragging = true;
console.log("onCircleMouseDrag");
}

[Michael Walmsley]

I had been attempting the same thing... is their any other way to stop propagation yet?

[Jürg Lehni]

In light of the recent event bubbling discussions, here an email to the whole list, as I'm curious to hear your thoughts.

The mouse events are a bit in state of mess right now. To explain why things behave the way they do:

Early on we have introduced the Tool objects that are provided to simplify the creation of drawing tools, since that's an area of focus for the library. In order to simplify their creation and teaching, we decided to support global event handlers in PaperScript that will automatically get associated with a tool object that's created behind the scenes for you.

After implementing hit-testing, I realized that it is rather easy to use that to offer some basic level support for item based events. Many people are reaching the limits of that right now because the events don't bubble up. 

The limits you are reaching are different: The fact that item level events cannot stop the execution of tool events. I actually think this is a feature, not a bug, since the two are on different levels altogether.

But here the solution for hopefully all these problems that I am currently looking into providing:

- I will add support for bubbling directly to the hit-testing code, through a callback method. This way I can support event bubbling on paper.js items.

- The View object will get support for mouse handlers as well. These will get executed if no item is hit, or if the hit item does not prevent propagation.

- Regardless of what will happen with propagation here, Tool events will always receive their callbacks, separately from the event bubbling infrastructure.

I think this is a pretty solid plan, with only one downside:

Since the global onResize / onFrame handlers in PaperScript are actually links to view.onResize / view.onFrame, I think it's weird that the global mouse handlers will not also be links to view.onMouseDown etc, but link to tool.onMouseDown instead (and the tool object is created on the fly)...

I'm considering changing this, and switching to tool objects for the more complex drawing tools. As soon as you use minDistance / maxDistance, you're handling the tool object anyhow. This change will obviously break backward compatibility of more complex drawing scripts, but I think it's important to keep the API consistent if we still can. That's also a reason why we haven't hit v1.0 yet, I'm still contemplating some API changes.

Thoughts?

J

--
You received this message because you are subscribed to the Google Groups "Paper.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to paperjs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.