Martin Vermeer <[EMAIL PROTECTED]> writes:
>> >> So... where is events ditched?
>> >
>> | Well, if you call processEvents with QEventLoop::ExcludeUserInput, what
>> | happens is (I think) that whenever the call empties the X event queue,
>> | those events that are user input (i.e., keystrokes among others) are
>> | silently discarded. This happens when LyX is busy drawing. When not,
>> | keystrokes are processed in regular fashion.
>>
>> So we are back to getting rid of processEvents completely then?
>
| Well, if you insist on not losing keystrokes, and we don't get 1.4
| speeded up enough... remember we're "only" competing with the human
| nervous system. We should win this :-)
We should do both. Both speed up and ensure that we cannot loose
keystrokes. (if something else throw the keystroke on the floor then
we dont care. But as long as the keystroke is delivered to use we
should do our best to handle it. (note: some keystrokes we actually
_want_ to get rid of. <page down> and hold it. The moment we release
the button we should prune _all_ queued up <page down> events. (that
same goes basically for all auto-repeat events (there are code in the
xforms frontend that tries to accomplish this.))))
>> or having our own queue of keyevents? (that would perhaps not be a bad
>> thing anyway... since then we could coalece keyevents and insert more
>> than one char at a time.)
>
| Where would you put this queue?
>
| If we get rid of processEvents entirely
I think that we clever/correct use of a queue, we can actually to the
processEvent at any time and as much as we want to. This would then
improve the feeling in some cases. (menus redrawn etc.)
|, all keystrokes come in through
| the Qt event loop. Every keystroke calls workAreaKeyPress, so that's
| where it should happen. Hmmm... I had one like that:
>
>
>
| @@ -511,7 +511,22 @@ void BufferView::Pimpl::scroll(int /*lin
| void BufferView::Pimpl::workAreaKeyPress(LyXKeySymPtr key,
| key_modifier::state state)
| {
| - owner_->getLyXFunc().processKeySym(key, state);
| + // Queue keystrokes during update/redraw/coord cache refresh.
| + // Needed as scripting requires no keystrokes are dropped.
| + /*
| +
| + key_entry ke;
| + ke = make_pair(key, state);
| + Q_.push(ke);
| + if (theCoords.isUpdating())
| + return;
| + while (!theCoords.isUpdating() && !Q_.empty()) {
| + key = Q_.front().first;
| + state = Q_.front().second;
| + Q_.pop();
| +*/
| + owner_->getLyXFunc().processKeySym(key, state);
| + //}
>
| /* This is perhaps a bit of a hack. When we move
| * around, or type, it's nice to be able to see
I would hope that we could leave the core out of this and handle this
solely in the frontend.
Also I think that in 1.5 we should try to get rid of workAreaKeyPress
entirely and move this into the frontend. Thus making dispatch(...)
the only mecanism for the frontend to communicate with the core.
(as such the frontend would just be another client)
| Would that really work? No characters are forwarded to LyX while drawing
| is going on. Would that eliminate the rendering glitches? I kind of
| doubt it... there are other events than keystrokes. We could
| shortcircuit mouse events in workAreaDispatch though.
Other events could be queued as well...
We could even have a queue of of deferred (user generated) events
stored in a queue (boost::function) that we only process say 20 times
a second. And if some update is in progress we just skip processing
events for that "time-slice"
I think it would work, and quite nicely.
--
Lgb
