On Tue, Sep 25, 2012 at 3:20 PM, Terry Brown <[email protected]> wrote:
> Why does update_style_sheet need sliderPosition()? I was trying to save and restore the slider position, but that doesn't work. Rev 5459 is an almost perfect fix for the problem. Here is the checkin log. QQQQQ A good, but not perfect fix for unwanted scrolling in the body pane: The problem was the call to w.setStyleSheet in g.app.gui.update_style_sheet. Apparently, this causes a layout-request event that spoils the scroll position. The fixes: 1. update_style_sheet does nothing if the new stylesheet is the same as the old. 2. Added lockout to mouseReleaseEvent. update_style_sheet does nothing if the lockout is set. 3. mouseReleaseEvent sets c.p.v.insertPoint if appropriate. Hitting Ctrl-H can still cause a small unwanted scroll, but now the insert point remains visible. QQQQQ My present mental model for what is happening is that various events can trigger a layout-request event, and apparently this gets honored at idle time. This request can reset carefully saved scrollbar positions. Or so I think now. Terry, your probe was useful in the debugging process, but really it just highlighted how strange the behavior is/was. I tried lots of workarounds, such as calls to repaint or blockSignals, all to no avail. As the checkin log indicates, this rev fixes a mostly unrelated bug: the mouse-click handler now sets c.p.v.insertPoint if the click happens in the body pane. This ensure that the line with the cursor is visible the next time focus returns to the body pane. There is still an easy way to get a small amount of unwanted scrolling. Just put the cursor at the end of a large amount of text in the body pane and then hit Ctrl-H. This will cause the body text to scroll so that the line with the cursor is at the bottom of the body pane. I don't know why this happens, but I think we can live with it for now. Note that this scrolling remains even if the g.no_see and g.no_scroll switches are on. That doesn't prove that Leo is innocent, but it indicates that the problem will be hard to find if Leo is guilty. I suspect that the latest code is at least as good as the Leo 4.8 code base. F.S., I hope you agree. Edward -- 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.
