Dov Feldstern wrote:
> Jean-Marc Lasgouttes wrote:
>>>>>>> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
>>
>> Peter> I've reproduced the error and fixed it. The problem was, not
>> Peter> only page up/down keys were dropped. This code does not work
>> Peter> (because of the implicit casts?)
>>
>> Peter> static const int delayed_keys = Qt::Key_PageDown |
>> Peter> Qt::Key_PageUp; if (e->key() & delayed_keys) {
>>
>> I know this stuff is very difficult to get right, but I do not like at
>> all the idea of testing explicitely qt::pageup/down. We should not
>> depend on these hardcoded keys. For example, your patch will fail for
>> people who use the emacs bindings and use Ctrl+v for page down. I am
>> not asking for adding another case for Ctrl+v (!) but I'd prefer a
>> solution which does not take this into account (especially since I do
>> not understand why only PageDown would be a problem (why is paragraph
>> down not a problem?)
>>
>> JMarc
>>
>>
>
> Peter, there's one thing I don't understand regarding this whole issue:
> doesn't holding the key down generate only *one* "key-down" and *one*
> "key-up" event? Whereas just pressing a key without holding it geenrates
> a single "keypress" event for every time it's pressed? (I don't know of
A page up/down key press event will be only dropped, if the last one wasn't
processed, so the auto repeated key press events could also produce
multiple scroll events.
> these are the correct terms, I don't know Qt at all, but the idea is
> probably the same). So couldn't we use that to differentiate? In other
> words, we should process every keypress event, and if that takes longer
> than it takes the user to generate them -- well, we should still process
> each one, because otherwise characters get swallowed; and if the
> keypresses are navigation keys, we should process those too --- every
> keypress the user presses means something. OTOH, if the user holds a
> key, we should just scroll or move or whatever as long as it's down, and
> stop as soon as the key is let go. How much we actually move or scroll
> or whatever will depend on the machine's speed, but that's fine: the
> important thing in this case is not to overshoot...
> I don;t know how mouse events fit in exactly, but I suspect it's
> similar: clicking multiple times on the scrollbar *should* "overshoot"
> --- i.e., every click should count. Holding the mouse button there,
> however, should not overshoot: as soon as the user stops pressing, the
> scrolling should stop.
>
> Again, I don't really know what I'm talking about, and I haven't been
> following the details of this issue very closely, but just in case this
> can be of some help...
>
