On Fri, 2007-03-16 at 18:29 +0000, Ricardo Cruz wrote:
> 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?
What I was saying specifically was that your patch *does not* result in
this; you are calling the "hook up to the GLib main loop to this
display" function. So, if you used your patch, then someone happened
to iterate the GLib main loop, suddenly your toolkit would start
mysteriously losing events.
> 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.
Really, all this Qt-theme-for-GTK+ GTK+-theme-for-Qt stuff is just a
horrendously bad idea. A vale of tears. What needs to be done is to
write a toolkit-independent theme engine system, hopefully less baroque,
strange, and broken then what we ended up for GTK+, and write themes
for that.
If written to exposing draiwng as pure drawing to a good graphics
API (cairo, specifically) it would also get rid of a lot of really
horrible things that the Mozilla folks are doing in the cairo
versions of Firefox.
> 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() ...
^^^^^^
window
Those are legacy names before cross-platform GTK+, so I'd rather have
a gdk_x11_* name.
> But if we go with a less functional GdkDisplay, we probably want the name to
> reflect that...
Maybe add a gboolean process_events parameter to it rather than trying
to encode that in the function name.
- Owen
Attachment:
signature.asc
Description: This is a digitally signed message part