Re: canvas event propagation

[Federico Mena Quintero <federico helixcode com>]

Brian Craft <bcboy@thecraftstudio.com> writes:

> The event handler for the GnomeCanvas gets called before any GnomeCanvasItem
> event handlers. The event handlers for items only get called if the GnomeCanvas
> event handler returns false. How is this useful?
> 
> Suppose you want to be able to rubber-band select items on the canvas, and be
> able to point & click select items. If you don't install an event handler for
> the canvas, you never get the rubber-band events. If you *do* install an event
> handler for the canvas, you don't know when the handler gets called whether the
> event should be passed to an item or begin a rubber-band select.
> 
> I don't get it. Shouldn't it be called *last*, when no items have handled the
> event? Like in a window hierarchy?

Lauris is right; it would be very convenient if the root canvas item
emitted events for the blank area of the canvas.  This should not be
hard to implement; you may need to insert a few special cases in the
code here and there.

The canvas event handlers get called first because they are the
standard GTK+ widget event handlers.  The canvas gets the events and
then runs its own internal functions to see which item should re-emit
the event it got.

People have been using an "acetate" item at the bottom of the canvas
to catch events on the blank area.  It would certainly be better to
have the root group do this automatically.

You can also look at code such as GnomeIconList to see how it captures
events on the canvas and optionally processes canvas item events; the
icon list does this to let you do rubberbanding.

  Federico