Re: Mouse wheel movement

[Bruce Stephens <b stephens isode com>]

"Gary V. Vaughan" <gvaughan@oranda.demon.co.uk> writes:

> Well, I haven't even looked at the source, but I get the impression
> from reading various docs, that an inheritance tree forms a major
> part of thegtk+ design.  I would presume that way up at the top of
> this tree is something akin to gtk_scrolled_widget; teaching this to
> understand the extra buttons would then be enough...

You might expect that (as I did), but that's not what I found.  As I
say, perhaps I was completely misunderstanding the structure, or (more
likely) overlooking some other feature that I could have used.

> > (I'm more used to Tk, where you can change arbitrary event bindings
> > at run-time, and adding wheel support for particular widgets wasn't
> > hard at all.)
> 
> Me too... though the scrollbar-to-widget communication set up is
> very bizarre, and I suspect (hope) no sane toolkit works like this!

Perhaps.  On the other hand, how else would you do it?  Different
widgets may have quite different ways of being scrolled (regardless of
any scrollbars): thus, they need some way of telling the scrollbars
about where they are.  

The underlying necessity of a two-way connection between scrollbars
(or scrolling controls---a panner is another one) and scrolled widgets
strikes me as unchanged, and quite logical, however you decide to hide
it.

An alternative would be to encode part of this complexity in some
higher-level combination, and then have widgets derive from it (thus,
the widgets would only need to override special bits of behaviour),
but of course, Tk doesn't have that kind of inheritance.  

Probably that's how Gtk+ is structured, but it seemed to me that the
recognition of the extra buttons would have to go in the underlying
widgets (the text widget, specifically), and not in the top-level
widget.  That's how the code looked, anyway.  Perhaps I was wrong,
though.