rjvbb added a comment.
In https://phabricator.kde.org/D5037#94944, @anthonyfieroni wrote: > Ok, we discard first wheel event cause elapsed timer isn't started, right? No, it's not discarded; no wheel events are being discarded unless they already were being discarded. What my addition does is turn certain Ctrl+Wheel events into regular wheel events so that the view continues to scroll when you press the modified during a scroll (instead of switching to zooming). There is no previous event so there's no need to do any checks to see if the modifier should be allowed to trigger zooming. So the first wheelevent just passes through the filter unmodified and if the modifier is pressed it will trigger zooming. Any other approach will probably only make things more difficult. And FWIW it's already semantically doubtful to set m_lastWheelEventUnmodified to false in the WheelEventFilter ctor (there is only a last event after the 1st wheel event has been processed) so putting it in the KateViewInternal ctor makes even less sense. Similarly, the timer must be specific to wheel events, you wouldn't want mouse movements to interfere for instance. Or at least I think so, I only have trackpads nowadays. Setting the modifier key in KateViewInternal does make sense but more so when it actually becomes possible to change it. Until that's not the case the compiler can optimise the current implementation a bit better (as far as that's of any importance here). > I think we can "catch" all events we just make it a bit different I don't think I understand what you mean here. What we don't catch is situations where the events tell the view to continue scrolling in a direction where that's no longer possible. My PoC implementation on github catches those situations but would be overkill (and probably interfere with zooming when the document is at the top or bottom). As to dropping wheel events: that doesn't happen but even if it did that shouldn't be a big deal if only 1 or a few events are dropped. This kind of event arrive in bursts from an effect-driven user input that isn't transient. IOW, contrary to clicking something, s/he will continue to turn the wheelbutton (or swipe up/down) until satisfied with whatever the desired result. I strongly doubt anyone one would notice if we dropped the 1st wheel event for instance. REVISION DETAIL https://phabricator.kde.org/D5037 To: rjvbb, #ktexteditor Cc: anthonyfieroni, dhaumann, kwrite-devel, #ktexteditor, #frameworks, head7, cullmann, kfunk, sars
