[no subject]

> You may well be well right that we should have worked on making
> GdkFont still work; it's certainly a bit of a API hole that there
> isn't a conventional character-by-character text drawing API
> available.

If this is a reasonable course, then perhaps the right idea is to create a 
new function that returns an Xft font for use by the rendering routines; 
that way legacy applications would continue to see only GDK_FONT_FONT and 
GDK_FONT_FONTSET but minor source modifications could switch applications 
to Xft fonts instead.  That would make porting existing Gtk+ apps to use 
Xft would require few changes rather than a wholesale conversion to Pango.

> But considering that we are releasing this weekend, it's not something
> we can go back and revisit at this point.
>
> (While adding a 3rd type of font may seem like a small API compatible, 
> change, it's actually something that can easily crash applications
> that aren't expecting it.)

Adding new APIs after the release that preserve source and binary 
compatibility for existing applications would probably be a better way 
than whacking gdk_font_load to return a new kind of object; the key is to 
require applications call a new function to get the new kind of gdk_font 
object.

Keith Packard        XFree86 Core Team        Compaq Cambridge Research Lab