Re: input only event boxes

[Owen Taylor <otaylor redhat com>]

On Mon, 2003-09-08 at 04:16, Alexander Larsson wrote:
> On Fri, 2003-09-05 at 17:00, Owen Taylor wrote:
> > On Fri, 2003-09-05 at 04:25, Alexander Larsson wrote:
> > > On Thu, 2003-09-04 at 16:25, Owen Taylor wrote:
> > > 
> > > > Looking good, I have some comments about the docs and see
> > > > one apparent bug. Otherwise looks good to commit.
> > > 
> > > I've fixed up this now, except one thing I don't understand:
> > > 
> > > > +      if (priv->event_window != NULL)
> > > > +	gdk_window_move_resize (priv->event_window,
> > > > +				allocation->x + GTK_CONTAINER (widget)->border_width,
> > > > +				allocation->y + GTK_CONTAINER (widget)->border_width,
> > > > +				child_allocation.width,
> > > > +				child_allocation.height);
> > > > 
> > > > Coordinates look wrong here for the case of visible && above_child.
> > > 
> > > How is this wrong? And how does the coordinates differ from !visible and
> > > visible && above_child? The INPUT_ONLY windows in both these cases go in
> > > exactly the same place, except in the visible case there is a
> > > INPUT_OUTPUT window at the same position, but under.
> > > 
> > > Am I missing something here?
> > 
> > OK, the bug is elsewhere :-), for any widget, whether NO_WINDOW or not,
> > all windows created by the window must be children of widget->window.
> > So, for the the visible && above_child case, priv->event_window must
> > be a child of widget->window, not a sibling of widget->window.
> 
> Ah, ok. Fixed this then. (attached)

Looks plausible to commit.

> However, this got me thinking about the above_child case. We can't
> really guarante that the event_window is above the children, because an
> app might unmap/map the child widgets of the eventbox while the eventbox
> is mapped. Is there any way to catch this, or do we just say "don't do
> that then"?

GtkButton, GtkMenuItem, GtkNotebook, etc have the same problem
potentially if you put children with windows in them.

Fixes would be:
 
 - Modify GDK to have some sort of "always above" flag for children.
 - For GtkEventBox, in the visible-window case, introduce a intermediate
   child (but then widget->window won't be the window that gets drawn
   upon, which adds confusion)

I don't think it's worth worrying about for now.

Regards,
						Owen