Comment #4 on issue 154 by atdi...@gmail.com: Zoom handler doesn't interact well with PSwing nodes
http://code.google.com/p/piccolo2d/issues/detail?id=154

This logic was introduced by Issue 15:

PPickPath::processEvent()

343 | if (event.isHandled()) {
344 |    return;
345 | }

But I'm not sure why this "short-circuiting" is required. When I remove it, I don't seem to be able to reproduce the behavior described in Issue 15; that is, I don't see events sent to overlapped nodes.

(1) Am I missing something?

But this short-circuiting does stop event handling up the pick path (so that ancestor node listeners won't get signalled). Is this really the desired behavior? When we short-circuit, the canvas-level handlers (pan, zoom) now won't get the event.

Without the above logic, event handlers can still do their own checking of event.isHandled() and decide not to handle the events. In addition, there's PEventFilter.setAcceptsAlreadyHandledEvents() that handlers can use.

(2) Does it make sense to remove this short-circuiting behavior in Piccolo 2.0?

We can't remove it in 1.4 point release for compatiblity but we could, in 1.4, make it a configurable capability to disable short-cutting, I suppose at the camera or canvas level, something like:

camera.setPropagatesAlreadyHandledEvents()

This would be false by default (backwards-compatible behavior) but could be set to true by clients wanting to avoid the bad zoom handling behavior. They'd have to do something like this to get the good zoom behavior:

camera.setPropagatesAlreadyHandledEvents(true);
// even w/o the short-circuting, by default the zoom handlers won't respond to already handled events,
// so we'd have to do something like this
PInputEventFilter ef = new PInputEventFilter(mask);
ef.setAcceptsAlreadyHandledEvents(true);
canvas.getZoomEventHandler().setEventFilter(ef);

(3) Thoughts?


--
Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en

Reply via email to