Re: [patch] snap to increment for adjustment

[Karl Nelson <kenelson ece ucdavis edu>]

> 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");

Neither of these look like particularly good practice.  No mather
what solution we implement, these likely should go away.

 
>   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.

Should there just be a function which does just that change the
limits and snap the value?

 
>   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()

That is good OO practice.  And I am happy to send a patch for
those places where it occurs.  I would go so far as say value and
such should be private and all things using adjustments should be 
going through method, though I know that that isn't really practical. 


>   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.

Unless the listener is already connected.  

> 
>  - 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.

That is one of the things I found quite annoying with scrollbars,
I wanted a scrollbar which adjusted the value from 0 to 360 (
for rotation) but I have to creat one to 0 to 360 + indicator width.

I agree definitely will need to consider interactions here.  I am
also wondering whether the indicator is going to bounce noticably
or have bad effects with the scrollbars.  However, I am sure these issues 
can be resolved.
 
> 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. 

Hmm.  I wish there was a good way to smooth over all these differences.


> 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.

Hmm.  The problem I see with connecting to value_changed is 
that we would need to stop_emission if the value isn't changed.  
Otherwise we end up with the possibly of creating changed
loops.  I am kind of on the war path to get "short circuit" logic
in place of many common function that way the used doesn't have to
worry about doing a set of the same value as was previously there
causing needless updates.  After all if they really want 
the thing to be registered as a change (even if there isn't one) they
can emit the raw *_changed signal.

The other problem with using value_changed is that you can end up
in a situation were the something connects to the adjustment before
the snap procedure did.  A simple case of this would be to create the
adjustment in a window and then borrow that for a spinbutton.  

Thanks for the reply.  Any thoughts?

--Karl