Re: client-side-windows vs metacity

[Owen Taylor <otaylor redhat com>]

On Sat, 2009-01-31 at 14:22 +0100, Alexander Larsson wrote:
> On Sat, 2009-01-31 at 07:43 -0500, Owen Taylor wrote:
> > On Sat, 2009-01-31 at 08:51 +0100, Alexander Larsson wrote:
> > > Yes, metacity is not getting a gdk leave event on the frame when the
> > > cursor moves from the frame to the client area. This happens because the
> > > event emulation code gets a "native" leave event on the frame to some
> > > position inside the frame, but the frame GdkWindow->children list is
> > > empty, so it doesn't generate a leave event for a child. 
> > > 
> > > We filter out the native events that we get on the toplevel, because
> > > they don't necessary match whats gonna be right when taking the client
> > > side windows into account. 
> > 
> > If you get an Inferior leave, you may be losing the ability to track the
> > pointer at that point ... the pointer may have disappeared deep into a
> > descendant of some foreign child. So I don't see how you can just ignore
> > it - it's going to need to be translated into one or more GDK leave and
> > enter events. (Depending on the current sprite window tracked by GDK and
> > the subwindow field.)
> 
> Hmm, what do you mean by current sprite window?

Sorry, "the (innermost) window that GDK thinks that the cursor is over".
It's terminology from the X server internals, which tend to use "sprite"
and "cursor" somewhat interchangeably.

> In general we don't just ignore it, we'll send leave/enter events on any
> to gdk known window inbetween the native window we got the event on and
> the known window at the position the leave event specifies.
>
> However, in this case the known window at that position is the toplevel
> itself, so we don't send any events.

The description above is a bit odd, I think you have to remember the
window where the pointer last was and take that into account in
determining where to send events, but perhaps you are just simplifying
in the description.

> > Same for Inferior enters, and in fact virtual enters/leaves as well.
> 
> Yeah.
> 
> > And once you are doing that translation, it seems reasonable to me that
> > if the subwindow field in the X event is a child you don't know about,
> > to:
> > 
> >  A) Generate events as if that child was an immediate child of the 
> >     window receiving the events. (Not a child of some CSW)
> > 
> >  B) Generate GDK events with a NULL subwindow - as GDK does currently
> >     in the Metacity case.
> 
> Yes, something like that might work. We should also avoid sending the
> normal enter/leave events to the location in the leave event.
> 
> Also, I guess this means we need to track enter/leave events on child
> windows too. Right now we just track it on the toplevel and do the
> enter/leave on native children ourselves. But with that approach we
> can't detect NULL subwindows leaves on non-toplevels. (We'd treat
> non-NULL subwindow leave/enter as more or less motion events on the
> toplevel though).

Yes, I agree that you have to select for enter/leave on all native
windows, or you won't have the needed value of the 'subwindow' field.

- Owen