On Wed, 2005-06-01 at 11:55, Lars Gullik Bjønnes wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes: > > | 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...) > > "I want to scroll down to next chapter beginning" > > how do you know when you get there?
1) You go to almost the right place using key repeat and the scrollbar. 2) You tap the PgDn key so it doesn't repeat, until you are there. The same as aiming a telescope: release fine motion, swing to the general area of the sky, clamp fine motion and aim precisely :-) > > > >> >> 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 ;-) > > Actually the difference seems to be minuscule. > > | I don't like your use of a key event queue in the front-end for > | achieving the effect. It's unnatural. > > Ohhh.... :-) > > Well I disagree. > > What the event queue accomplishes is to say that: "We do not allow > auto-repeat events to queue up faster than we are able to handle > them." > > If you have another way of achieving that goal then I am all ears. So am I. I suppose it is fundamentally impossible as in the LyX core you cannot manipulate the X/Qt event loop. > | But I don't see any other way, > | except processEvents, which is anathema as I argued before. > > processEvents is ok as long as we don't misuse it. > (and that is easy to do...) ;-) - Martin
signature.asc
Description: This is a digitally signed message part
