> On Fri, 2005-03-04 at 23:02 +0100, Andreas Klostermann wrote: > > I try to fix a bug in the gtk frontend. When moving the cursor "out of > > sight", normally the view should follow it by centering. Now, with the > > gtk frontend, it will scroll crazily around, making the application > > unrespondible. > > > I'm trying to fix it, but I don't quite understand the flow of signals. > > Could someone give me details on how this works? > > A while back, Alfredo Braunstein wrote: > > I know what this it: the gtk frontend fires the "scrolling" signal > > when > > setting the scrollbar parameters from inside LyX: the kernel expects > > that > > setting the parameters only changes the scrollbar visually (and > > invokes no > > scrolling). This results in an infinite loop. > > There was a similar problem in the qt frontend, that was solved by > > deactivating the signal somewhere IIRC. Unfortunately I cannot look at > > the > > problem more closely ATM. > > To illustrate the situation more clearly for you, in GWorkArea.C: > line 196: > vscrollbar_.get_adjustment()->signal_value_changed().connect( > sigc::mem_fun(*this, &GWorkArea::onScroll)); > > So onScroll gets called whenever the adjustment object associated with > the vertical scrollbar is changed. Fine. That's there to catch user > input. However, at line 356 in setScrollbarParams (which the backend > calls): > adjustment->set_value(pos); > > That in turn triggers onScroll, which tells LyX to scroll, which tells > the frontend to update its scrollbar, ad infinitum. >
Well, I thought, that the setScrollbarParams method is only called once - upon initialization.
