Re: Routing scroll events in a Gtk.Overlay

[Robert Schroll <rschroll gmail com>]

On Wed, Jun 4, 2014 at 11:19 PM, Paul Davis 
<paul linuxaudiosystems com> wrote:
> You should know that GTK's design more or less does not cater to 
> overlapping GtkWidgets. It is not completely clear if you are 
> actually doing this, but it certainly sounds as if you are. The API 
> allows you to create overlapping widgets, but nothing else in the API 
> (though I admit to knowing GTK3 not as well as I should) defines 
> event handling when this happens. Z-axis (or "stacking) ordering 
> needs to be defined for this to be done rationally. GTK does not 
> provide this as far as I know (GTK2 definitely does not and I don't 
> think GTK3 changed this).

It seems to be behaving perfectly sensibly.  Scroll events go to the 
widget directly under the pointer, whether that's the overlaid or the 
underlying widget, and the bubble up through the parents.  What I'm 
asking (I think) is if there's a way to change that sensible behavior.  
(And I have found one, but it involves scroll-event handlers on every 
widget.)

We don't need to consider overlays, if that's worrisome.  Consider a 
composite widget, say an EventBox with a whole hierarchy of children.  
Is there some way to make one type of event go directly to the 
EventBox, while others go through to the children?  I'd hoped I could 
do this with set_above_child() and set_events(), but I haven't been 
able to make that work.

Thanks,
Robert