Re: Xft and Xrender support for GTK+ 1.2.8

[Havoc Pennington <hp redhat com>]

"Bryan O'Sullivan" <bos serpentine com> writes: 
> h> I think it's important to know what stability guarantees Keith is
> h> ready to make for Xft.
> 
> Not very many for now, I think.  Still, the patch seems worthwhile to
> me anyway, even if I end up maintaining it separately until Xft
> becomes more solid.  It just doesn't do to have Qt shipping with such
> sexy features without a near-term response :-)

Right, no doubt it would be popular for people to apply the patch,
even if we don't put it in GTK. ;-) I think it's reasonable to
investigate putting it in GTK, but we don't want to compromise the
stability of the stable branch, so lots of care is required.
 
> Good point.  This also makes me wonder if it's also unsafe to store a
> pointer to an XftFont object in a GdkFontPrivate's xfont field.
> Clients of the library might conceivably want to access what they
> think is an XFontStruct or an XFontSet.  Do you have any thoughts on
> this?  (My inclination is to let such clients choke for now.)

The existence of gdkx.h, which includes gdkprivate.h, means that GDK
1.2 is effectively much more tightly bound to X (and the specifics of
X fonts) than we might like, at least in terms of what can be changed
without breaking apps. There are lots of pieces of GNOME that poke
around in the X stuff because GDK lacks API for various X-specific
things. If you look through the gtk-list and gtk-app-devel-list
archives, it's pretty common to take some old Xlib code and make it
draw in a GtkDrawingArea, or try to interoperate with Motif widgets,
and stuff like that.

A solution here might be to always load an XFontStruct or XFontSet,
even though it won't be used, then _also_ load the XftFont and tack
that on the end of the struct, or some hack like that. So if someone
was using the xfont field, they will still get a valid XFontStruct.
 
> Do you mean that clients of the GDK library actually want to cast the
> semi-opaque structs into their private equivalents and munge them or
> call sizeof(), or are you just referring to the badness of config.h
> being included?

I'm not sure whether anyone could depend on sizeof(GdkWindowPrivate)
and such. I guess it's unlikely. Definitely though, if we add a field
it should be done by just sticking a 'gpointer xft_data' in the header
unconditionally, rather than according to config.h.

> Regardless, I can get around the conditionally-sized GdkWindowPrivate
> by socking an XftDraw object away in a hash table instead, which is
> awkward but workable.

Might be the best route, just to be on the safe side. You could also
use the g_dataset_* API from GLib, which just associates data with
some pointer, that is probably better.

I guess the way to think about it is to try to have Xft "piggyback"
both at compile time and at runtime, so that all the normal
XFontStruct codepaths end up running when possible, same data
structures end up existing, and we only magically swap in XftFont at
the very last minute.

Jacob was saying the hard part was GtkFontSelection - do you have that
working yet? ;-)

Havoc