On Sep 30, 8:12 pm, "Edward K. Ream" <[email protected]> wrote:
> > 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. Rev 4512 fixes one part of the bug, the part relating to mouse clicks. I've been writing up my notes as I went along, but now I see that they were sent only to Viktor. To summarize: This was a "worthy" bug. After much searching, I found the culprit: the call to keyboardQuit at the end of leoQtBaseWidget.mouseReleaseEvent. Presumably, this caused problems by generating *new* events in the body pane, with lugubrious consequences. In retrospect the event handler should have been easier to find. But that's only in retrospect: there are a *lot* of events being generated, but the mouseRelease event isn't being shown to the eventFilter method because QTextBrowser implements its own mouseReleaseEvent. And of course there is no call to w.connect for such events... The fix was simply to execute k.keyboardQuit at idle time, using g.app.gui.runAtIdle. I didn't investigate what the proximate cause of the problem was, but presumably k.keyboardQuit generates new events that interfere with the event handler. Added comments about two other event handlers that call significant code but which do not seem to cause problems--presumably because the code does not generate new events in the same widget. I just realized that the problem persists for keystrokes. Presumably a similar fix will work for them too. I'll fix this immediately. 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.
