Re: why do constructors return GtkWidget?

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


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