Re: [patch] snap to increment for adjustment

[Owen Taylor <otaylor redhat com>]

Karl Nelson <kenelson@ece.ucdavis.edu> writes:

> A frequently asked question on the gtkmm list is how to make
> an adjustment snap to increments.  Since this functionality already
> exists in gtk+ in spinbutton, I would propose that we move the
> functionality from spinbutton to adjustment, so that the snap
> functionality is available to all widgets.  I have composed and
> tested a patch to do that.  I also altered spinbutton to remove
> redundant functionality.  Hopefully, it will be considered reasonable 
> for inclusion.
> 
> If we want to get really fancy we could make a virtual function in 
> the adjustment which does the snap and clamp stuff in set_value so 
> that one could easily derive a adjustment type.  That way people
> who want really strange adjustment snap settings like CD player settings
> (1,2,4,6,8) could just derive an adjustment and change the snap
> vfunc.  This is not implemented in the patch, but I could add it
> if we consider it necessary.

Hmm, this look basically reasonable, but I have a couple of concerns:

 - gtk_adjustment_set_value() is not very widely used currently.

   If you look at the GTK+ source code, it is considerably more common
   to do:

    adj->value = new_value;
    gtk_adjustment_value_changed(adj)

  or even;
   
    adj->value = new_value;
    gtk_signal_emit_by_name (GTK_OBJECT (adj), "value_changed");

  Sometimes this is done for no good reason, but in other cases,
  it is done this way when changing both the limits and the value,
  so you never get ::changed or ::value_changed emitted with
  the old value and new limits or vice versa.

  We could fix all cases in GTK+ to use set_value() when possible
  and then say snap_to_increment doesn't work unless you use
  set_value()

  Another approach is to do the snapping in the default handler
  for ::value_changed. Since value_changed is run_first(), 
  the listener cannot distinguish between this and your approach.

 - There are a quite a few cases where the range of allowable
   values for the adjustment is not lower <= value <= upper
   but lower <= value - page_size <= upper. 

   This is generally enforced in code that is done by the 
   user before set_value() - the snapping to ticks will
   destroy this.

   So, if you set snap_to_increment true on, say, the vadjustment
   for a scrolled area, you might see odd effects, or even
   blatant misbehavior.

   The only real way I can think of handling this is to add another
   flag to GtkAdjustment to indicate that range should be 
   modified by the page size.

Another thing to note is that snapping and step increments
are not always tied together. The GtkScale widgets snap
to the precision of the scale, not to the step size. I don't
know if this is a problem in practice - at least programming
in C, you can always connect to ::value_changed, and do the
snapping yourself.

Regards,
                                        Owen