Re: "Parent" comment and font question

[Owen Taylor <otaylor redhat com>]

Matthew D Allen <s2mdalle@titan.vcu.edu> writes:

> It seems sort of strange that gtkwidget.h provides "accessor" methods for
> most of the items within a GtkWidget ala OOP, but it doesn't seem to have
> one for the *parent node within a widget.  I.e. I came across a spot where
> I would want to know if a given widget was the child of a GtkNotebook, and
> I wrote:
> 
> int is_child_of_notebook(GtkWidget *input){
> 	GtkWidget *ptr;
> 	if(!input) return(0);
> 	ptr = input->parent;
> 	while(ptr){
> 		if(GTK_IS_NOTEBOOK(ptr)) return(1);
> 		ptr = ptr->parent;
> 	}
> 	return(0);
> }
> 
> I would think that this would be a bad idea, but I don't know of another
> way to do it.  

This is OK (although the check itself seems odd, and as a matter
of C style, I'd write:

gboolean is_child_of_notebook(GtkWidget *input)
{
 	GtkWidget *ptr = input;
 	while(ptr) {
 		if (GTK_IS_NOTEBOOK(ptr)) return TRUE;
 		ptr = ptr->parent;
 	}
 	return FALSE;
}

But as it happens, there _is_ a nice easy way of doing this
particular operation:

 if (gtk_widget_get_ancestor (widget, GTK_TYPE_NOTEBOOK))
   /* do whatever */

> I'm accessing a piece of data within the GtkWidget object,
> which I thought was a big OOP no-no.  If for some reason the GTK+
> developers rename the "parent" item to "foobar" or whatever (I don't have
> any clue why they would do that, but for the sake of argument) then my
> code would be broken, whereas if there was a
> 
> GtkWidget *gtk_widget_get_parent(GtkWidget *something);
> 
> avalible, there wouldn't be a problem.  

Well, in essence, its our problem, not yours. ;-)

We've said (implicitely, but once GTK+ is documented in the RDP,
explicitely) that the 'parent' member of the GtkWidget structure is
public for reading (but not for writing! You must never modify the
members of Object structures directly), so we know that:

 - Changing the size of the GtkObject structure or the position
   of the parent member of the GtkWidget structure breaks binary
   compatibility.

 - Changing the name of the field, or removing it breaks source
   compatibility.

And we won't do either accidentally. Yes, it would be sort 
of nice to have accessors for all interesting fields in GTK+,
but the amount of code out their that accesses the the fields
directly means we couldn't change the field names/positions
anyways.

And actually, the way deriviation works in GTK+ gives you
the same fragile-base-class problem you have in C++ anyways,
so you have to be very, very careful about modifying object
structures anyways if you want to preserve binary compatibility.

Regards,
                                        Owen