Source files are no longer separated by UI and non-UI and similar,
but only by their build target.
* ui/ -> part/
* Move all source files from conf/ to part/
* Keep config skeleton definitions in conf/, needed for the mobile target too
* Move editdrawingtooldialogtest.h from conf/autotests/ to autotests/
* ui/data/icons/ -> icons/
* Move /part.cpp, /part.rc and similar files to part/
* Adapt include paths in source files
* Adapt CMakeLists.txt files (in / and in subdirectories)
* Adapt /Messages.sh
The condition was incorrect; we were ignoring history when not in the
middle of scrolling when we wanted to do the reverse.
BUG: 414701
FIXED-IN: 20.12
apt-get uses several fsync() calls on each package it installs, and that's
very slow, especially on non-SSD. eatmydata turns fsync into no-op, which
makes package installation much faster (it can cause corruption if there's
power loss or similar, but that doesn't matter in CI where we throw away
the whole container anyway).
Currently the build_ubuntu_20_04 job in GitLab CI takes 8-9 minutes to
install dependencies. Using eatmydata it went down to 2 minutes.
And by that it means giving the focus to the pageview which is most of
the fimes what we want. One could argue that if i had the focus on the
searchbar we should restore the focus there, but that makes not much
sense to me, since each tab is it's own world, at most one could say,
let's remember where the focus was in that tab the last time it was
focused and restore it there, but it seems a bit convoluted.
To be able of setting the focus to the pageview from the shell we need
to set up some focus proxies, so that part->widget (which is the sidebar)
ends up giving the focus to the pageview, which is what makes sense if
someone says "you part, set yourself the focus"
BUGS: 428257
When holding down the shift key, multiply wheel and touchpad scroll
distances by 10 to re-implement the fast scrolling feature that
broke when we added animated/smooth scrolling.
BUG: 420889
FIXED-IN: 1.11.3
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
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
