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. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
