Re: Routing scroll events in a Gtk.Overlay

[Robert Schroll <rschroll gmail com>]

On Thu, Jun 5, 2014 at 1:19 PM, richard boaz <ivor boaz gmail com> 
wrote:
> instead of using GTK to route the events correctly, is it not 
> possible (possibly preferable) to route all events to your own 
> handler which you yourself can further negotiate and forward to the 
> necessary widget?

I hadn't considered that solution.  This whole thing is supposed to 
live beside other GTK widgets in a toplevel window.  My immediate 
reaction is that wouldn't work, since it would also trap events going 
to those other widgets.  But I'll think about it some more.

On Thu, Jun 5, 2014 at 1:28 PM, Paul Davis <paul linuxaudiosystems com> 
wrote:
> AFAIK, events propagate only via parent/child relationships (i.e. 
> container/contained). So an event delivered to a widget that just 
> happened to overlap another one but had no child/parent relationship 
> with the covered one would never forward events to the covered one 
> under any circumstances.

So I guess my question becomes, how can a parent (the EventBox) prevent 
a certain type of event (scrolling) from being delivered to its 
children.  The default handling works the other way, starting from the 
children and bubbling up.  Using set_above_child(True) makes the parent 
get the events instead of the children, but that works for all events, 
not just the one I want to trap.

Thank you both,
Robert