Re: ScrolledWindow scrolling strategy: follow child widget focus?

["Bryan W. Headley" <bwheadley earthlink net>]

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


--
____               .:.                 ____
Bryan W. Headley - bwheadley earthlink net