On Wed, 2005-05-11 at 17:33, Lars Gullik BjÃnnes wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes: > > | Oops, that's bad. Could this be due to calling sync_events twice during > | a cursor blink sequence? (both in showCursor and in hideCursor.) I did > | that to make LyX snappier ;-/ > > Hmm... this shouldn't be needed to make LyX snappier... > > | Alternatively, now the time between two calls to processEvents is never > | shorter than 0.4 sec. Could that be the problem? This time is set in the > | BufferView::Pimpl::Pimpl constructor. (Actually this isn't quite true: > | there are some calls to showCursor in the code where the blink counter > | is forcibly reset.) > > Why should we have to call processEvents explictly at all? Shouldn't > the main Qt eventloop handle this for us?
Finally, finally somebody asking the right question! I disabled this stuff at the source (lyx_gui.C:259) and the keystroke-order problem went away. So, indeed it seems that there were two ways of bringing keystroke events into LyX: the Qt event loop, and processEvents. Weird that they shouldn't know about each other; but if that really is so, it would explain the observed behaviour. It's a bit like in the old Basic microcomputers, where you could read a char from the keyboard using getChar equiv., or peek from a hardware register, but rather not both ;-/ What came back was the original problem why sync_events was introduced: when scrolling fast in big documents (PageDown) the screen update doesn't keep up. - // You are not expected to understand this. This forces Qt - // (the problem case) to deal with its event queue. This is - // necessary when holding down a key such as 'page down' or - // just typing: without this processing of the event queue, - // the cursor gets ahead of itself without a selection or - // workarea redraw having a chance to keep up. If you think - // you can remove this, try selecting text with the mouse - // in Qt, or holding Page Down on the User's Guide. Well, AFAICS that's only cosmetic. (Question: were there any non-cosmetic problems with this? I don't see any.) I think we should completely dump processEvents/sync_events. With BIG comments explaining why. - Martin
signature.asc
Description: This is a digitally signed message part
