Comment #4 on issue 154 by [email protected]: 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
