Overlapping widget behaviour and a motion_hints anomoly

["Steven M. Campbell" <scampbell sequoianet com>]

Okay, I've figured out most of what I need for my "widget manager" in a
window  (Thanks Emmanuel for the excellent suggestion of working at the
fixed container level, that was much simpler than my "wrap a new widget
around it" idea).   My very last hurdle is this.  On a fixed container
if widgets overlap GTK seems to handle this fine, it knows which one is
"on top" and which is "below" (ie. you can overlap text boxes and one
will obscure the other's contents properly) but is there anyway for me
to tell which widget is "on top"?   It appears that the widget mapped
last is the one that's "on top" so I could trap the map/unmap events and
build my own table but that's rather kludgy as I've no guarentee this
behaviour will be forward compatable with new versions of GTK.

Also, I've noticed a small anomoly using motion_hints.  When I trap all
mouse motion for the fixed widget and set motion_hints I get hints
unless the cursor moves into another widget at which point I revert to
pure motion events until I leave that widget.  This is not particularily
troublesome to me as the code (if motionhints then read the mouse xy)
handles it and my motion routine is fast enough to stand full blast
motion events anyway.  I just mention this as this behaviour might cause
some surprising slowdowns in some peoples apps.  It is possible to set
motion_hints on all your widgets manually and bypass this problem if you
wish but really should hints/nohints be set as a result of widget
trapping the event as opposed to the widget the cursor is over?   Just
seemed odd to me.