This afternoon I once again encountered a scrolling bug. I searched for some text, manually scrolled the body pane, and then next click caused chaos, that is, an unwanted and disconcerting scroll.
Since then, I have been unable to duplicate the bug, but I am quite sure I wasn't dreaming :-) In an effort to squash this bug, I have disabled all the code that saved and restored the vertical scroll position of the body pane. Instead, the code saves and restores the insert point, then calls w.seeInsertPoint() to force Qt to make the insert point visible. This change *might* fix the bug, and it *might* work as well as the previous code. It certainly should eliminate any kind of "race" condition between w.see and w.setYScrollPosition. But questions remain: 1. Will it, in fact, fix the scrolling bug once and for all? 2. Will approximating the scrollbar position be good enough when re- editing a node? I strongly suspect that it will: it's not a question of the body text "jumping": the body text is completely replaced whenever we switch nodes. It's merely a question of whether restoring the *approximate* scrollbar position will in any way become irritating. Again, I doubt it, but we shall see. Please report any new scrolling problems immediately. Edward P.S Here is the checkin log for rev 4504: Eliminated all code that saves and restores the body pane's scrollbar position, using instead w.see and w.seeInsertPoint. My *guess* is that there were (rare) cases when the w.see clashed with setting the scroll point. The new code is simpler and can not cause such clashed. More testing is needed to see if it works well enough. All the new code is marked with ### 2011/09/30. All unit tests pass. EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
