updateCursor() was called by wheelEvent(), which made sense,
because after the wheel event the page will have moved under the cursor.
With smooth scrolling, it makes less sense in wheelEvent(),
because at that point scrolling is still in the future.
scrollContentsBy() appears to be called on every scroll step.
(It is documented to be called at scrollbar value changes, so makes sense.)
This patch removes updateCursor() from wheelEvent(), but adds it to scrollContentsBy().
I did not check anything out with d->visibleItems, as was indicated it graphics/okular!176.
BUG: 421437
This fixes scrolling with the scrollbar,
so it is not reset when scrolling on the viewport afterwards.
PageView’s QSroller was not correctly updated by update_scroller,
because it was connected to QAbstractSlider::sliderMoved and sliderReleased,
which are only emitted while the “slider is down”,
i. e. not when the user scrolls the scrollbar other than dragging the slider.
Now update_scroller is connected to actionTriggered(),
which is emitted for all user interactions.
Note that scrolling using the scrollbar calls QAbstractScrollArea::scrollContentsBy(),
and so bypasses smooth scrolling of the QScroller. This could be considered a feature,
otherwise it is more a bug in Qt than in Okular, because we can not ignore scrollContentsBy().
Steps to reproduce:
1. Open a long document
2. Click on the vertical scrollbar below the slider
3. Okular scrolls one page down
4. Scroll in the viewport
5. Okular starts scrolling from the position from step 1.
Test plan:
* Scroll using scrollbar
+ Click on the vertical scrollbar below the slider
+ Middle-click on the vertical scrollbar below the slider
+ Click on the little arrow of the vertical scrollbar
+ Scroll using a scrolling device (e. g. `xdotool click 4`) on the vertical scrollbar
+ Drag the slider of the scrollbar
* “cross-product” verify QScroller state
+ Scroll using a scrolling device on the viewport
+ Scroll using Browse tool dragging
+ Scroll the viewport by clicking a point in the thumbnails view
+ Scroll the viewport using arrow keys and Page Up/Down keys
BUG: 421159
Selecting highlight tool, pressing left mouse button while over text, and
immediately releasing without dragging a selection caused inconsistent state.
It left TextSelectorEnigne in the state m_creationCompleted == false and
m_lockedItem == something. Then in continuous mode all events kept on being
propagated to TextSelectorEngine::event, even if the user started unrelated
interactions in the meantime. This caused various side effects.
It notably happened when you double clicked a finished highlight annotation,
as described in bug 426658.
We can go to m_creationComplete after release even without a selection,
because TextSelectorEngine::end and PageViewAnnotator::performRouteMouseOrTabletEvent
handle the case just fine, i.e. don't create an annotation but reset the state machine.
Fixes bug 426658 at least partially. I couldn't reproduce the described crash,
so no idea if that's also fixed.
BUG: 446658
`setViewport` automatically adds an item to the history if it finds that it
moved for more than a page, which we don't want to do when automatically
scrolling, as with inertial scrolling.
This commit adds a new function `setViewportWithHistory()` which takes an
argument to optionally avoid preserving history. This avoids breaking ABI.
The new history-less functionality is used when inertially scrolling.
BUG: 421354
FIXED-IN: 1.11.2
Even though the animated smooth scrolling transitions are now affected
by the global animation speed setting in Plasma, this is not totally
satisfactory for the full pool of people who hate smooth scrolling, as
it does not address the cases of people using Okular outside of Plasma
or people who generally want animations but just not in Okular's
scrolling implementation.
Accordingly, there is now a GUI option to disable smooth scrolling in
Okular's settings window.
BUG: 420755
FIXED-IN: 20.12
Unite handling of right click in mouse release event
Before we had handling on press -> show annot menu if annot
and in release -> show link menu if link or show the genericmenu if nothing
Now we do everything on release and do
show link and annot menu if both
show link menu if link
show annot menu if annot
show generic menu if nothing
It helps with the fact that you can't click on links if there's an
annotation on top, which is a bit of a pain but it makes sense since
annotations usually have more interaction than links, you can select,
move, etc. them
BUGS: 425291
Bug 421159 involves a combination of scrolling with the scroll bar
and the mouse wheel. This patch adds an autotest for the bug,
to make sure it doesn't come back.
David Hurka
l10n daemon script
Albert Astals Cid
Oliver Sander
Nate Graham
Tobias Deiminger
Christoph Feck
Simone Gaiarin
Kishore Gopalakrishnan
Luigi Toscano
Antoni Bella Pérez
Kezi Olio
Rafael Sadowski