On Wed, 2005-06-01 at 11:05, Lars Gullik Bjønnes wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes: > > >> Ok. I did my tests. > >> > >> I must admit that I now find it unusable. No feedback on screen when > >> using cursor keys for movement (on auto-repeat) > >> > >> Same with PageDown/PageUp. (except from the scrollbar) > > > | Which I think is good enough. > | I don't want to pay the price of rendering > | _every_ intermediate screenful. OTOH fast scrolling using the mouse > | exists. > > I don't. I think it is really surprising behaviour. And in pratices > you force users to use the mouse for scrolling more than a couple of > screen fulls.
No, I meant that just the other way around. The fact that fast mouse scrolling exists allows us to make keyboard scrolling slow... as your event queue for ex. does. The slowness will drive people to use the mouse for fast positioning within the document, which I again dislike. (and about "surprising behaviour": only the first time. You get used to it, and _like_ it, real fast. And it does no damage...) > >> The scrolling problem is fixed by adding in the event queue, > > > | Fixed in what way? > > syncing the screen updates with the downward movement. I.e., slow ;-) I don't like your use of a key event queue in the front-end for achieving the effect. It's unnatural. But I don't see any other way, except processEvents, which is anathema as I argued before. - Martin
signature.asc
Description: This is a digitally signed message part
