Re: ScrolledWindow scrolling strategy: follow child widget focus?

"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);

There's an example in testgtk.c?


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