Re: Questions about event percolation

[otaylor redhat com]

Ramiro Estrugo <ramiro@netscape.com> writes:

> Hi,
> 
> It is my (limited) understanding that events in the gtk widget sysem
> percolate from children to parent until someone handles it and returns
> TRUE.
> 
> Now, lets say i have a container (a GtkLayout widget actually) and this
> container has one child, say a button or entry widget.
> 
> I connect a "motion_notify_event" to the container.  I set the events
> for the container as appropiate.  
> 
> The signal is triggered for motion not only within the container, but
> its children as well.
> 
> So, the motion signals handlers will be triggered as if the the child
> was invisible.
> 
> Ok, so I install the signal on the child, set the child events as
> appropiate and then return TRUE in that signal - a noop.  
> 
> Is this the only way to avoid the motion signals from being emitted for
> the case when you are mousing on the child ?
> 
> Is there any way to tell the gtk signal system to emit signals only for
> the container window, and not for sub windows ?

No way to tell GTK+ not to emit the signals, but it should
be easy enough to filter them out in your handler:

 if (event->window != GTK_LAYOUT (layout)->bin-window)
    return TRUE;
 
> If not, are there any effeciency concerns about having to install every
> single signal on every signal child (along with setting the events,
> which i preseme ultimately does the x lib selection of event) ?  

Well, it will be slower and more space intensive. The speed
probably isn't a huge concern, but memory bloat may be significant.

It is 32 bytes per signal handler, and there are 9 signals
that are propagated in this way, so that is 288 bytes per
widget.

Regards,
                                        Owen