Re: Adding foreign_new_xdisplay for Gdk X11

[Ricardo Cruz <rpmcruz clix pt>]

You wrote (@ Friday, 16 de March de 2007 18:29):
> 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.
>
 Ah, okay. But my Xlib knowledge is the experience of some web browsing. :) I 
really didn't want to come up with a patch in the first place, because this 
is a sensitive area, just did, because I knew nobody else would. :)

> >  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.
>
 Yeah, I had the same thought, and I feel the same way regarding Qt and GTK+ 
style framework and have some ideas on how they could be better... The 
problem is that you would have to also come up with a graphics drawing API.

 Maybe not a big issue, but it adds up. We would need to be responsive to 
people, fixing what they dislike and make sure what they dislike, etc, and 
feel the framework is well supported, so we can get them to do styles for it. 
I can't afford the time for that.

 But in fact, as a sub project, I have shaped Qt style framework to a much 
easier to write styles for. If people started using it and working on it, it 
would benefit the project, and them. And a style written for it would be much 
easier to port than an ordinary one.
( http://gtk4qt.sourceforge.net/qsimplestyle/ )
 Something like that could eventually turned in what you say (make a Cairo 
backend for QPainter and more of such).

> 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.
>
 I guess we could write a Cairo backend for QPainter and so on. But I am sure 
the KDE style authors won't like the idea, to say the least. If we do the 
opposite (Qt4 supports for such), GTK+ people wouldn't like it either (would 
you? :)).

> >  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.
>
 Okay, didn't know that. Yeah, x11 is a good prefix.

> >  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.
>
 Okay. Even if we don't support events just now, it would be scalable.

Thanks,
 Ricardo

> 						- Owen

-- 
Maternity pay?	Now every Tom, Dick and Harry will get pregnant.
		-- Malcolm Smith