Spin button sugar

[Mike Kestner <mkestner ameritech net>]

This is a request for comment on a proposed resolution to bug 50278.  

I've done a rather unscientific spin button usage analysis from GNOME
CVS. After looking at in the neighborhood of 100 instances of spin
button construction, I found only a couple apps that are sharing the
spin button's adjustment with other widgets. The lion's share of
instances don't.  Most code snippets look like the following:

	adj = gtk_adjustment_new(...)
	sb = gtk_spin_button_new(adj,...)
	gtk_signal_connect(adj, "value_changed",...)

The bug report calls for a convenience API for creating and accessing
spin buttons.  I propose the following changes:

Rename the existing constructor to:

gtk_spin_button_new_with_adjustment(GtkAdjustment *, gfloat climb_rate,
guint digits);

Add a new convenience constructor:

gtk_spin_button_new(gfloat value, gfloat min, gfloat max, gfloat
step_incr);

The new constructor would set climb_rate to page_incr.  Most users
currently use either 0.0 or step_incr anyway.  Digits would be derived
from the precision of step_incr. The page_incr would be set by an
algorithm like:

page_incr = MIN (10 * step_incr, (max - min)/10.0)

For the majority of cases, this would give a usable spin button very
similar to what people are coding manually.  A large chuck of the
existing instances have adjustments with a 1/10 step/page ratio.  For
the less common cases, it's probably best to use the existing
constructor and roll your own adjustment anyway. 

If we also add a spin_value_changed signal and some get/set_value
methods, we can allow users to live in ignorant bliss of the underlying
adjustment object. All of the attributes can be made private, as the
adjustment is the only interesting attribute and it already has get/set
accessors.

Any suggestions/comments on this resolution?  I'll begin coding in a day
or two unless the proposal is determined to be the drooling babble of a
moron.

Regards,
Mike