Martin Vermeer <[EMAIL PROTECTED]> writes:
>> - 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.
It is effective because of the work you did witht he sync_event
stuff...
| - QContentPane::keyPressEvent is called for every time you press a key,
| right? Is this asynchronous?
yes. no idea, I guess not.
>
| - keyeventTimeout is called every 0.05 seconds, _always_; right? Is
| _this_ asynchronous?
in my updated patch I set the timeout to 25ms, but use a one-shot
timer instead. This avoids a problem I saw where som keyevents envokes
an operation that takes more than 25ms. After keyeventTimeout is
finished with its work the timer is restarted and kicks in after 25ms.
If it is async? Tja... I guess you could define it as that.
| - 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?
??
They are just kept in a queue...
In my updated patch queued up auto-repeat keyevents are pruned.
| - 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.)
order reversal... if a new key event is received after another event
has begun handling you can get unlucky and have the second event
handled before the first one...
So by making the event en-queuer a lot faster it is harder to trigger
the problems... but they still exist. (or so I belive)
Can you reproduce the order reversal? If so please test my latest
patch.
--
Lgb
