Re: client-side-windows vs metacity

[Owen Taylor <otaylor redhat com>]

On Sat, 2009-01-31 at 08:51 +0100, Alexander Larsson wrote:
> On Fri, 2009-01-30 at 14:48 -0500, Owen Taylor wrote:
> > On Fri, 2009-01-30 at 20:38 +0100, Alexander Larsson wrote:
> > > I'm running a full gnome session with the client-side-windows branch
> > > here. There are a few minor issues I'm working on, but overall it just
> > > works(tm). I'll send a new status report soon.
> > > 
> > > However, there is a specific issue with metacity that I'd like some
> > > feedback on. Metacity uses gdk to handle the frame window for managed
> > > children. This window will get the clients window reparented into it,
> > > however metacity never accesses that window as a gdk window (i.e. it
> > > doesn't call gdk_window_foreign_new on the xid) , so gdk doesn't know
> > > about it.
> > > 
> > > This means that as gdk knows there are no children of the frame, and
> > > thus the event emulation code won't send a leave for inferior event to
> > > the frame when the mouse moves from the frame to the client window. This
> > > means metacity won't reset the cursor on the frame, thus affecting the
> > > default cursor in the client window. (In X the default cursor is
> > > inherited from the parent.)
> > >
> > > Now, how do we solve this? There are two possibilities. Either we add
> > > special code to metacity so that it creates the child window as a gdk
> > > object and keeps it updated as to the size when the frame is resized.
> > > 
> > > Or, we add some hacks to gdk to track this case and make it work. One
> > > way is to detect native Inferior Leave events on windows with no
> > > children and use XQueryTree to find the windows. Resizes can be tracked
> > > with ConfigureEvents. I'm attaching a patch that implements this.
> > 
> > Although I believe there is a problem, It's not clear from the above
> > what it is. Is there problem that Metacity isn't it getting a GDK leave
> > event? If that's the problem, why can't you just convert the native
> > event to a GDK event and send that along?
> > 
> > And how are ConfigureEvents related?
> 
> 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.)

Same for Inferior enters, and in fact virtual enters/leaves as well.

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.

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

- Owen