On Thu, 27 Sep 2012 11:51:13 -0500 "Edward K. Ream" <[email protected]> wrote:
> On Tue, Sep 25, 2012 at 3:50 PM, Edward K. Ream <[email protected]> wrote: > > > Rev 5459 is an almost perfect fix for the problem. > > But not perfect enough, imo. As noted, Ctrl-H will still cause > unwanted scrolling. > > Looking at the sources, I see that w.setStyleSheet generates an > internal polish event, which presumably is the culprit. So the border must be present at all times, and only change color, not thickness, otherwise the text will wiggle as the border comes and goes. Given that, can't the scroll position be read before the call to w.setStyleSheet? I know that's obvious and there are all kinds of complexities of which I'm blissfully unaware, but it seems the scroll position should be right. Also, is the problem really restoring the scroll position? Seems the scroll jump would occur as the current body gains and loses focus, even when no node switching is happening. So can scroll position restoration be suppressed except for a one time thing when a new node is selected? Really, it's very simple when you don't know what you're talking about :-) Cheers -Terry > I am beginning to think that changing the stylesheet in order to draw > the border is a fools errand. An alternative would be to embed the > body pane in a plain widget, and just set the background color of that > widget. Presumably, that would not cause a wholesale restyling of the > embedded text widget. In fact, it should have no effect on any > embedded widgets. > > In any case, the present situation is intolerable. > > 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.
