The next release of gnome-utils, 2.13.90, will make libgdict adhere to the API/ABI freeze, even if it’s not part of the Gnome Developer Platform but only of the Desktop.
The freeze had been in effect since the last release (January 18th), and I planned not to change libgdict API; unfortunately, when writing the support for the document_font_name
GConf key, which was introduced in Gnome 2.12 and that should be honoured by any application showing arbitrarily long texts to the user, I noticed that a call to gtk_widget_modify_font
to a GtkContainer
does not propagate to the containers’s children. The widget the Dictionary uses to display the text of the definitions is, in fact, a composite widget (a GtkVBox
) as it needs to hold the text display and the find bar; the inner widgets are held inside a private structure, and are not visible to the outside.
If I wanted to work around this, I would have written something like this function inside the code of the libgdict users:
static void gtk_container_modify_font_children (GtkContainer *container, const gchar *font_name) { GList *children, *l; PangoFontDescription *font_desc; g_return_if_fail (GTK_IS_CONTAINER (container)); font_desc = NULL; if (font_name) { font_desc = pango_font_description_from_string (font_name); g_return_if_fail (font_desc != NULL); } children = gtk_container_get_children (container); for (l = children; l != NULL; l = l->next) { GtkWidget *widget = GTK_WIDGET (l->data); gtk_widget_modify_font (widget, font_desc); } g_list_free (children); if (font_desc) pango_font_description_free (font_desc); }
But it would not have worked; I wanted to change the font of the GtkTextView
widget inside the GdictDefbox
, while the function above would have changed font for all internal widgets – including the find pane.
Assigning a name to the GtkTextView
widget, say “text-display”, by using the gtk_widget_set_name
function, and changing the code of the inner loop to something like this:
... for (l = children; l != NULL; l = l->next) { GtkWidget *widget = GTK_WIDGET (l->data); const gchar *name = gtk_widget_get_name (widget); if (strcmp (name, "text-display") == 0) gtk_widget_modify_font (widget, font_desc); } ...
I would have avoided the API breakage inside libgdict – but I would also have created a performance bottleneck, since I transformed a constant time operation into a linear time one (from an assignment to a list walk) – plus, I don’t know what happens into gtk_widget_modify_font
; also, I would have created a documentation issue, since I now would have to document the widget’s name and hope that nobody would ever have the urge to change the GdictDefbox
font – at least, not after having had lunch.
Giving a name to the inner children of a composite widget is always a good practice – it makes handling these kind of situations easier; but between an hackish approach and a breakage of an API freeze, I would rather choose the latter. Hacks tend to get sticky, and you get a design by accretion if you let them stick around enough.
So, I opten for adding a new property to the GdictDefbox
widget, called font-name
, and its two accessor functions:
G_CONST_RETURN gchar *gdict_defbox_get_font_name (GdictDefbox *defbox); void gdict_defbox_set_font_name (GdictDefbox *defbox, const gchar *font_name);
Which are just proxies for the gtk_widget_modify_font
function. Since nobody uses libgdict (it’s been out there only for the folks using Ubuntu or jhbuild), the breakage is really minimal; nevertheless, I feel a bit guilty for not having tested this stuff before, in time for the freeze.