Re: Expressing the desired stacking of *Action-managed actors

[Samium Gromoff <_deepfire feelingofgreen ru>]

Evening, folks;

Another page in my cluttered diary..

To reinstate some context -- I'm trying to have a pannable viewport
onto a field populated by draggable ClutterActors.

As far as I understand Clutter's model, this translates to a combination of:

   - parent actor, with a PanAction attached
   - a set of children actors, with personal DragActions attached

The problem is with children's DragAction -- once the PanAction hits the
movement threshold (as directed by GestureAction), the children stop
getting the events, and PanAction takes over, because it attaches a
"captured-event" handler to the ClutterStage itself.

Samium Gromoff <_deepfire feelingofgreen ru> writes:
> Hmm, I'm looking at the implementation of GestureAction, and
> particularly at clutter_gesture_action_set_actor(), and it appears, at
> least on surface, that filtering could be done via a combination of
> g_signal_override_class_handler() and
> g_signal_chain_from_overridden_handler(), as applied to the
> "captured-event" signal - emitted on the actor object.
>
> Am I entirely wrong, or, perhaps, there is a better way?

Turns out, only "object methods" ("class methods" would be a more
fitting name, I guess) can be overridden in the GObject model.

So, for conditionalisation of the PanAction's "captured-event" signal
handler, it appears that one has to install a signal handler to the
scroll actor before the PanAction is attached.

Once we're preceding the PanAction handler, we can control whether the
event reaches that handler by returning CLUTTER_EVENT_PROPAGATE or
CLUTTER_EVENT_STOP.

So far so good.  But then we need to deliver the event to one of the
scroll's children -- that is, if the event actually belongs to a child.

So, we either manually iterate over children, "picking" the first (if
any), whose bounding box covers the event.  Or we opt to use
clutter_stage_get_actor_at_pos(), which could be more or less expensive,
but is certainly more precise, if we choose to have complex Cogl children.

Very well, we have our candidate.  Now what?

Would g_signal_emit() be effective at invoking the DragAction attached
to the child?

-- 
regards,
Samium Gromoff