Re: why do constructors return GtkWidget?

[Emmanuel Touzery <emmanuel touzery free fr>]

Hi,
> There is a technical difference when writing GTK+ code in C; for instance
> its quite often that you will access methods on the GtkWidgetClass
> (like show()/hide()/set_sensitive() etc), also many other apis take GtkWidget *
> argument, namely GtkContainer apis which operate on child widgets.
>
> > From this standpoint its alot more convenient to cast all your widget variables
> as GtkWidget * (this way you keep casting to a minimum in your code) so GTK+
> is only helping you by returning GtkWidget *, if only for a simple and
> practical
> reason to save you a little casting/typing.
>    
Thank you for the answer. I meant no technical difference for the 
correctness of the new* method, to return either GtkWidget* or the real 
type. It seems from that point of view, both could be returned and are 
technically correct, so which to return is only convention.
And it's the same for methods that should take GtkMenuItem* (for 
instance) to take that or GtkWidget*.

I understand what you mean, but for me the big problem is that it's very 
difficult to have methods like this:

GtkWidget *text_entry, *menu_item, *button;

I find it very ugly and hard to follow, I much prefer having:

GtkEntry *text_entry;
GtkMenuItem *menu_item;
GtkButton *button;

Which means that at this point in my C/GTK development I'm always 
casting to the "real" types when invoking a constructor:

text_entry = GTK_TEXT_ENTRY (gtk_text_entry_new ());
button = GTK_BUTTON (gtk_button_new ());

And this doesn't shock me at all:
gtk_container_add (GTK_CONTAINER (parent), GTK_WIDGET (button));

In fact it makes a lot of sense to me.

Well in any case. If you want like me to have "real" types in the code 
this convention is not helping at all.

You know what I'm thinking... I think that this is from times where 
people used to build GUIs in the code... When they were writing all the 
container embedding and all, in C, building their dialogs. At that time 
that convention surely helped, you were constantly adding widgets to 
containers and so on. Today this is done in gtkbuilder and so what we 
have left is code not doing so much embedding in code (though obviously 
it happens) but certainly more manipulation of the real types 
(gtk_entry_get_text, and so on). But now because of this convention, 
yes, if you want to store real types you'll get more casts :-(
However if the convention was changed I think there would be less casts 
or more or less the same number of them. But the number of casts is 
secondary to me, having the real types in the declarations in the code 
is much more worthwhile I think.

Well in any case. Right now I changed my own widgets that I wrote to 
return their real type in the _new() methods. I don't know if I'll 
revert that, I'll see. I'm also using the real types in my declarations, 
though I'm paying the price with casts. Maybe I'll just give in and do 
it the GTK way...

emmanuel