Re: client-side-windows vs metacity

[Alexander Larsson <alexl redhat com>]

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?

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.

> 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).

> > The solution is to create a GdkWindow object for the client window so
> > that the event emulation machinery is aware of the child and everything
> > works. The configure event is required to update the size of the foreign
> > child when the frame changes.
> 
> I don't like the QueryTree, I don't like tracking ConfigureEvents on a
> random subset of foreign windows. If we need to track the existence and
> position of children, then selecting for SubstructureNotify upfront
> seems more appropriate.

Yeah. Its far from nice, it was just an ugly hack to make it work. But,
I think the above strategy will be enough to make this work. So, no need
for that stuff.