On Thu, May 12, 2005 at 06:47:50PM +0200, Lars Gullik Bjønnes wrote: > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: > > | | Then we just need a timer that kicks in some 10-20 times a second to > | | check the queue and do the real work. > > > | and with the queue doing the right thing we can actually put > | processEvents allover as much as we want to to make the interactive > | feeling better. Because we know that all events that is sendt to lyx > | core is queued up until we allow them to be handed. > > this is kindo a proof-of-concept. > > Would be nice if people could try this a bit and see if the problems > seen earlier can be reproduced with this patch applied. > > - most likely a check for update in progress is needed in the > keyeventTimeout > - event coalescing would be nice... (may be 1.5 stuff if we go this route)
On risk of appearing dense, would you please go over this patch step by step and explain what it is doing, and why it appears to be effective. - QContentPane::keyPressEvent is called for every time you press a key, right? Is this asynchronous? - keyeventTimeout is called every 0.05 seconds, _always_; right? Is _this_ asynchronous? - Where precisely are keystrokes being held back until "we" (the LyX core?) are ready to handle them? How do you know (and _who_ knows) when that is? What happens above and beyond keystrokes being collected and dispatched in neat little packets of 50 msec? - Why does the call to processEvents now only rarely find any unprocessed keyboard event? (Apparently that is the reason we only see occasional order reversals.) I honestly don't get the logic of this. Head scratching, - Martin
pgpcXT1mGK6mV.pgp
Description: PGP signature
