ScrolledWindow scrolling strategy: follow child widget focus?



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 :-)


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




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