Re: [gtk-list] Re: scrollbars and signals

[Owen Taylor <owt1 cornell edu>]

Nathan Froyd <maestrox@geocities.com> writes:

> Nicholas Lamb wrote:
> > 
> > On Fri, 30 Jan 1998, Nathan Froyd wrote:
> > 
> > [On the subject of Adjustments]
> > [deleted]
> > Uh? How does this let me connect a Scrollbar and a slider together?
> > Now I would have to write loads of "look in the scrollbar, put the
> > value in the slider" and "look in the slider, put the value in the
> > scrollbar" code. And the code which cares about the value elsewhere
> > must know which I have used, a slider or a scrollbar... Arrrgh!
> > 
> > I think a few extra lines of code here and there are not much to pay
> > for the advantages of the current design.
> 
> What advantages, in particular do you see? It's not that hard to write a
> little extra code in the app to work with returned values from
> scrollbars. Say you wanted RGB to HSV (like the ColorSel widget). You'd
> simply have the RGB sliders connected to a common callback, which would
> register the RGB values and translate them into the equivalent HSV
> values. Finally, you'd set the HSV scrollbars. Of course, you'd work in
> reverse (sort of) to go HSV->RGB. I'm still not convinced of the wisdom
> of creating a separate adjustment object for each range (scrollbar,
> slider, whatever).

The Adjustment objects encapsulates the idea of an adjustable
object (slider, scrollbar, dial), without forcing every such
widget to be derived from a common ancestor. In languages that
support multiple inheritance, this could possibly be done
using that, but GTK's object system doesn't support that. 
(And you would have to have multiple inheritance of signals, not
just of methods)

There are a few side benefits you get from it as well:

 - you can have multiple linked adjustments.
 - you can have adjustments without any visual representation at all.

But these aren't the main point.

I think you'll find that the extra object is _not_ a big deal
from the user's point of view. And it is at least as flexible
as any conceivable alternative.

Regards,
                                        Owen