Re: Adding foreign_new_xdisplay for Gdk X11

[Owen Taylor <otaylor redhat com>]

On Sat, 2007-02-10 at 08:59 -0600, Federico Mena Quintero wrote:
> El mar, 06-02-2007 a las 16:43 +0000, Ricardo Cruz escribi� 
> >  I am writting a Qt style that uses GTK+ to render its stuff; the inverse of 
> > gtk-qt-engine [1], and so I need to re-use the Qt Display connection.
> 
> Nice!  This would even help for gradually porting ancient non-GTK+
> software to the new world order.
> 
> >  Would 
> > it be possible to add a function with the following signature to Gdk X11?
> >  GdkDisplay *gdk_x11_foreign_new_xdisplay (Display *)
> > 
> >  I have made this patch for mine 2.8.18:
> > http://www.alunos.dcc.fc.up.pt/~c0607045/trash/gdkdisplay-foreign.patch
> 
> Your gdk_x11_foreign_new_xdisplay() doesn't emit "display-opened" on the
> GdkDisplayManager.  The display *was* already open, but shouldn't the
> display manager get to know about this?
> 
> GdkDisplay keeps some interesting state (last-clicked-window, button
> click times, etc.).  If GTK+ doesn't really own the display, could these
> fields get out of sync with reality?  Does it matter?

This is certainly a concern of mine as well... GDK does expect to be
getting events on a display:

 - To update XSettings ... if GTK+ doesn't get events, then it won't
   catch (among other things) theme changes
 - To remove elements from the queue used for translation and 
   anti-exposes. (it no longer grows without bounds, but there is
   some performance penalty for not trimming it)
 - To know when windows are destroyed

And in fact, with your patch GTK+ will happily consume events for that
display if you run the GLib main loop in any way!

This is likely going to cause disaster if your function is used inside
GTK+-adapted OpenOffice.org or Qt4 compiled to use the GLib main loop.
(I believe that that is now possible.)

So, I'm not sure this patch really answers to me the question of how you
integrate GTK+ with a foreign display.

 - Events for GTK+ windows need to be delivered to GTK+
 - Events for non-GTK+ windows that GTK+ knows about via 
   gdk_window_foreign_new() need to be delivered to *both* GTK+ and
   to the other toolkit. The event mask for such windows needs to be
   the union event masks that each toolkit wants. (DND / cut-and-paste
   won't work properly without this)
 - Events on the root window need to be delivered to both GTK+ and
   the other toolkit, with the same caveat about the event mask.
 - Other events need to be delivered to the other toolkit.

You can probably hack much of that up using GDK filter functions, but
it's a pretty darn big can of worms.

For your purposes, you'd probably be better off modifying your patch
so that the call to  _gdk_events_init() was skipped, but that returns
you to having a GDK with a number of things that don't quite work (not
counting the big things that don't work like expose events!)

					- Owen

P.S. - gdk_x11_foreign_new_xdisplay() would be better as
       gdk_x11_display_new_foreign().