Re: Xft and Xrender support for GTK+ 1.2.8



h> You might want to mail jacob ximian com who was also hacking on a
h> patch for this.

Will do.

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 :-)

h>  typedef enum
h>  {
h>    GDK_FONT_FONT,
h> -  GDK_FONT_FONTSET
h> +  GDK_FONT_FONTSET,
h> +  GDK_FONT_XFT_FONT,
h> +  GDK_FONT_XFT_FONTSET
h>  } GdkFontType;
 
h> This could break existing code - [...]

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.)

Anyway, I can get rid of the extra enum fields, I think, and change
the way the internal Xft-dependent code is parameterised so that the
fields aren't necessary.

h> The conditionally-changing struct size in gdkprivate.h won't work
h> either, because that file gets installed and used, despite its
h> name.

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?

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.

h> (Also, gdkprivate.h shouldn't include config.h for that reason.)

Fair enough.

h> Don't you need to check in gdk_init() whether the server supports
h> the Xft extension, in addition to checking whether Xlib supports it
h> at build time?

Yes.  That falls under the category of "things I know I need to do,
but could get away with ignoring in the short term".

Thanks for the helpful comments.  This is exactly the kind of feedback
I was hoping for.

	<b




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]