Re: Minutes of the GTK+ Team Meeting - 2008-09-23

["Morten Welinder" <mortenw gnome org>]

> I disagree. If we keep gtk_hbox_new() and gtk_vbox_new() around,
> we can't change the packing defaults, which is a *huge* benefit
> of introducing a new class with new API (GtkBox was abstract before,
> so now allowing to instantiate it is in fact a new widget, and
> that has to be reflected in *new* API to be able to change its
> behavior).

A "*huge* benefit"?  Would you care to elaborate, concretely, what the
"*huge* benefit" of overriding defaults could be?
How does it compare to the cumulative "*enormous* pain" distributed
over all application developers?

We are discussing changing a very fundamental widget class here.  I
don't care too much what you do with GtkHScale -- just keep
gtk_hscale_new around as a convenience function.  (I call it that so
you don't get the idea that it should be deprecated.)
But GtkHBox?  Do you really want to send another giant "Fuck You!" to
anyone who has working Gtk+ code?

> Also, can we simply change the return value of functions?
> (returning a GtkBox where we used to return GtkVBox and GtkHBox).

gtk_hbox_new returns a GtkWidget*.  As long as GTK_HBOX and
GTK_IS_HBOX exist and do the right thing, breakage should be minimal.

Morten