Created attachment 45119 [details] [review]
treeview_simpler_api.patch

Created attachment 45124 [details]
gtktreeview_defaults_test.c 

Example to show how to use this API, and how it uses less code.

IMHO this should end up being in extra files. gtktreeview.[ch] is more than
large enough already.

about the TODOs

int/long   -> value_number = strtol (new_text, NULL, 0);
uint/ulong -> value_number = strtoul (new_text, NULL, 0);

I really don't like this approach to simplifying GtkTreeView.  First of all, I
think that any _with_defaults() function is right, as no one knows what the
defualts are.  Secondly, it doesn't address the bigger problem people have with
GtkTreeView, which is the M/V/C split.  If we're going to provide a simpler API,
I'd rather see it be of the form:

list = gtk_simple_list_new (G_TYPE_BOOLEAN, GDK_TYPE_PIXBUF, G_TYPE_STRING,
G_TYPE_POINTER);
gtk_simple_list_append (list, FALSE, pixbuf, "Foo", my_data);

Which would create a GtkTreeView with 3 columns, each with one renderer (toggle,
pixbuf, and string).

> no one knows what the defaultts are.
We can document them, and they are pretty obvious anyway. We have been doing
this successfully in gtkmm since 2.0.

>we're going to provide a simpler API, I'd rather see it be of the form:
>
> list = gtk_simple_list_new (G_TYPE_BOOLEAN, GDK_TYPE_PIXBUF, G_TYPE_STRING,
G_TYPE_POINTER);

That would do much the same thing, and could in fact be implemented with these
functions.

And these functions would still be useful in order to make changes to the
default without implementing the whole thing. For instance, you can add a
default cell renderer but provide your own validation of edited values. That's
common enough to be worth API.

I fully agree with Jonathan on this point. Also, I don't really see why the
_with_default() functions are useful, they might save typing, but that's about
everything I can come up with.