Re: ScrolledWindow scrolling strategy: follow child widget focus?

[Owen Taylor <otaylor redhat com>]

"Bryan W. Headley" <bwheadley earthlink net> writes:

> Owen Taylor wrote:
> > "Bryan W. Headley" <bwheadley earthlink net> writes:
> >
> >>I have an application with several entry widgets (yeah, and
> >>multiselect-comboboxes :-) that exists in a scrolled window. For a
> >>touch typist, being able to tab from one entry field to another,
> >>that's off-screen causes a problem, insofar as the user's required to
> >>manually adjust the scrollbars.
> >>
> >>I rigged something at the child widget level, which fires off on
> >>focus_in, checks it's position vis-a-vis what the HAdjustment and/or
> >>the the VAdjustment widgets are set to, and moves the scrolled window
> >>around. Heavily in debt to what libgtkhtml does to affect the same
> >>behavior (but does not require the container is a GtkLayout)
> >>
> >>Is this behavior pattern something we'd want to put into the
> >>ScrolledWindow as a parameter? I ask, because I get to wire up 150
> >>signal callbacks :-)
> >>
> >>Agreements? Disagreements? I'll work it into a patch & throw it into
> >>the bug tracker if y'all like...
> >>
> >>Asking why I have 150 entry widgets in a scrolledwindow will yield no
> >>useful answers :-)
> > Are you looking for:
> > void   gtk_container_set_focus_vadjustment (GtkContainer
> > *container,
> > 					    GtkAdjustment    *adjustment);
> > void   gtk_container_set_focus_hadjustment (GtkContainer     *container,
> > 					    GtkAdjustment    *adjustment);
> >
> 
> No, I'm looking for a Scroll Policy that makes the adjustments happen
> automagically. So, really, you're looking at calling
> gtk_container_real_set_focus_child() being called as a part of the
> child's "focus-in" default callback

Have you tried using those functions? Have you looked at the example
in testgtk? I can't see how the behavior differs from what you are
describing.

Regards,
                                        Owen