GNOME Bugzilla – Bug 63768
Can't instantiate a GtkTreeStore with just g_object_new()
Last modified: 2005-12-22 15:09:14 UTC
*_new() functions should be just convenience wrappers, but there doesn't seem to be a way to instantiate a GtkTreeStore with only g_object_new() as there are no construct-time properties to correspond to the number of columns, and array of column types. At the least there should be a public gtk_tree_store_constructv() function that's called from gtk_tree_store_newv(). I'm happy to code that if necessary.
The same applies to GtkListStore.
Created attachment 5984 [details] [review] Adds properties to GtkTreeStore, GtkListStore and GtkTreeModelSort
The patch, also posted to gtk-devel, fixes this.
Committed a fix. Rather than use the construct properties to ListStore and TreeStore, I added a ::set_column_types function that can be called immediately after the object is created. The rationale for this is that the G_TYPE_POINTER value for the array of types is basically useless, and possibly dangerous.
This is enough for gtkmm, but I'm not convinced that it's enough for language bindings and GUI-builders in general, because it still doesn't seem possible to instantiate a *valid* GtkTreeStore with just g_object_new(). How is the use of gtk_tree_store_set_column_types() immediately after g_object_new() any different than the now-incorrect use of _construct() functions? After I made this patch I noticed that there is an array parameter type. Maybe this would be useful.
I'm not sure. This is essentially a construct function. However, an array of Types is pretty ugly. Maybe we can add one later for 2.2, but not for 2.0
Well, officially the use of construct functions instead of construct-time properties is incorrect, so this bug should stay open, with a different target milestone. Then it can be fixed later.
"Officially" is up to the library API designers ... there are a lot of other GObject types you can't instantiate with g_object_new() - GdkWindow, GdkVisual, PangoLayout, .... I could go on and on. In any case, a G_TYPE_POINTER typed parameter does absolutetely _nothing_ for a GUI builder. It is a C only API as much as what we have now. I'm putting this on the future milestone with Severity Enhancement, but IMO, it probably isn't really worth worrying about this at all.
Reassigning bugs to new component owner. Sorry for the flood.
Looks like the remaining problem here is closely related to bug 81040: G_TYPE_GTYPE is missing from fundamental types.
Yes, that looks useful.
Closing this. Thank you. We'll see if any glade developers complain when they try to implement model-design in Glade.