On Thu, May 12, 2005 at 06:19:39PM +0300, Martin Vermeer wrote: > On Thu, 2005-05-12 at 17:53, Jean-Marc Lasgouttes wrote: > > >>>>> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > ... > > > So it seems that my brilliant idea was a bit lousy. I do not see what > > Qt machinery could help us, except perhaps QApplication::postEvent. We > > could setup an eventFilter for the application that fileters user > > input events and posts them for later. > > No, it wasn't lousy. "Eating keystrokes" is bad only if it also eats the > scripted events reaching LyX though a scripting interface; this is what > Andre objected to in one of my earlier clever ideas. Here, there is no > such danger: this keystroke eating only affects real, physical > keystrokes from a human being containing slow, wet electrochemical > circuitry sitting at the keyboard. > > We should just get LyX faster than 99% of touch typists, then the > problem goes away.
Sigh. How do you know it is a typist, and not something fancy like: * barcode reader (or similiar device) connected to the keyboard cable? These devices inserts whole strings as fast as the hardware can receive. Lyx can't know this. * Some cut/paste mechanism outside lyx, such as X pasting or even better: some "paste utility program" messing with the os keyboard driver? Lyx may figure out X pasting, but not the other case. * os support for OCR into the keyboard buffer, a page at a time . . . Loosing keypresses that actually got delivered to lyx won't do. Even a horribly lagging lyx is better than that. (Loosing autorepeats _by design_ is of course ok.) Helge Hafting
