understanding flow of events

[cheshirekow <cheshirekow gmail com>]

Some background: I'm working on a project for building block-diagrams.
I'm using a Gtk::Layout as the view for the diagram. The view-class for
the blocks is a class which extends from Gtk::Frame. The block widget
will contain a couple of interactive components so that it can be moved
around, resized, and so that a signal path can be started from that
block. Since block diagrams can get pretty big, I'd like the view to be
scalable. I'm using the unstable gtkmm-2.99 branch (for now). I've
implemented the scaling quite easily by overriding the Gtk::Layout's
on_draw method and scaling the cairo context before calling the
base-class on_draw method. This works quite well, except that, for
testing, I've put some buttons inside the Block view-class and they are
activated when the mouse is moved over their would-be-if-unscaled
location, not their location as-drawn. This is not exactly unexpected,
but it does cause a problem.

The question: For widgets that do not have X-Windows (in this case the
Button), how are input events passed to them? I would assume they come
from the first ancestor widget which *does* have an XWindow. If so, is
there a way to filter/process/intercept these messages before they get
to the child? In this case, I would like to scale the coordinates of the
mouse cursor before it is determined which child widget to pass the
event to, so that the button's are not activated (mouse-over'ed)
incorrectly. Also, how does the parent widget know which child to pass
events to? If events are not-passed from parent-to-child in this way,
then probably I will have to implement custom signals so that the
Gtk::Layout can pass mouse events to it's children (where appropriate),
which is fine... but I prefer not to reinvent wheels.

I'm assuming, here, that widgets without XWindows actually do still get
input events (though not the raw GdkEvent__). This is based on the fact
that the Gtk::Button's that I've used are highlighted when the mouse is
over them even though they are listed as not having an XWindow here:
http://library.gnome.org/devel/gtkmm-tutorial/unstable/chapter-widgets-without-xwindows.html.en

Though, since the branch is unstable this may not be accurate... and it
may in fact be that the button's do have an XWindow and they're becoming
activated because that XWindow is generating input events. It may also
be that the button's have an event-box... so while they are drawing on
the parent XWindow, and not one of their own, their input events are
coming from a separate window.

Sorry for the long text, but if there's anyone that can help answer my
questions or point me to some documentation that will clear up some of
my confusion, I would greatly appreciate it.

Thanks, 

Josh