Re: ScrolledWindow scrolling strategy: follow child widget focus?

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]