Re: Adding foreign_new_xdisplay for Gdk X11

[Ricardo Cruz <rpmcruz clix pt>]

Owen Taylor wrote (@ Thursday, 15 de March de 2007 15:55):
> 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ó:
> > 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.)
>
 Qt 4.2 documentation says that Glib main loop can be plugged easy to Qt's 
(sad they only have a line on this). But if someone does some mixing of Qt 
and GTK+, how will this style affect that? We have our own GDK 
initialization, so they don't get to know about the existance of our 
GdkDisplay. It should be no different than two different GTK+ applications. 
In fact, we could very well be using different GTK+ versions.

 I'm only interested in getting a GdkDisplay wrapper to Display to issue 
drawing events. I might need to plug the GTK+ event to know of style changes, 
but I should be able to do this in a safe manner by having GTK+ loop going 
afterwards Qt's. That isn't entirely safe though... But can't we just have 
GTK+ ignoring that GdkDisplay at all?

 So, can't we just have some function to wrap a Display connection to a 
GdkDisplay whose only purposes is to send drawing commands. This surely 
reduces the already small usefulness of it, but think about the style 
wrappers like that of OpenOffice, who do all their work offscreen and then 
clutter the connection to the server with it. Pretty inefficient.

 Am I missing something?

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

 Not sure how I come up with that name. :/ Anyway, gdk_display_foreign_new() 
might be better since gdkx has gdk_pixmap_foreign_new() and 
gdk_display_foreign_new() ...

 But if we go with a less functional GdkDisplay, we probably want the name to 
reflect that...

Cheers,
 Ricardo

-- 
You are only young once, but you can stay immature indefinitely.