On Sun, Oct 2, 2011 at 10:36 PM, Edward K. Ream <[email protected]> wrote:
> This has turned out to be one of the thorniest bugs I've ever > encountered. > I'm not sure whether the unwanted scrolling is because I am > overlooking some of Leo's code (it's surprisingly difficult to > determine all the event-related code that gets executed) or because of > glitches, if not outright bugs, in Qt itself. The present not-quite-perfect behavior could be attributed to layout-request events that follow the mouse clicks: - Saving/restoring scrollbars don't work because the new layout messes with them. - w.ensureCursorVisible doesn't work perfectly because the new layout changes the cursor position in the scroll area (although now the cursor at least remains visible). This morning I tried two approaches: 1. QWidget.blockSignals in mouseReleaseEvent. 2. Ignoring LayoutRequest events in the event filter. The first fails because the layout-request events get generated *after* the mouseReleaseEvent completes. As a desperation measure, I added a call to c.frame.top.update() inside the "blocked signals" area, hoping that would clear event queues without generating an event. But no joy. The second fails for utterly mysterious reasons. Leo's event filters sees the event, calls event.accept() and returns True, which should be enough to kill the event, but isn't. At present I am out of ideas. It looks like the (fairly rare) unwanted scrolling will continue. Anyone have any ideas? 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.
