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
`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
QScroller uses a minimum drag distance before drag scrolling starts by default.
This sets the minimum distance to 0.0, to restore the original behavior of the Browse tool.
BUG: 420842
This uses KConfigWatcher to listen for changes to the relevant config
value and update the speed dynamically, rather that just once when the
app is launched.
Now people who don't like animations can set thenm to "Instant" globally
and smooth scrolling will be effectively disabled off in Okular.
There is no change in speed for people using the default global
animation duration.
BUG: 420755
FIXED-IN: 1.12.0
This is safe now that the animated transitions no longer block repeated
scroll actions during the animation.
This partially reverts 08d368c13b
BUG: 422041
BUG: 425850
FIXED-IN: 1.11.2
When the view is paged (ie, non continuous), and an annotation is
selected while the user navigate through pages, the annotation
selection will become an artifact in other pages. Besides that,
the annotation will still receive keystrokes (such as delete).
Steps to Reproduce:
- Open a PDF file with Okular
- Draw an ellipsis annotation in the document
- Select the ellipsis
- Change to the previous or next page
This fixes the jagged freehand lines problem.
It was caused because tablet events were not accepted, and so were delivered again as mouse event, creating an additional line point slightly offset, causing sharp line angles.
BUG: 410723
FIXED-IN: 1.11
This fixes the jagged freehand lines problem.
It was caused because tablet events were not accepted, and so were delivered again as mouse event, creating an additional line point slightly offset, causing sharp line angles.
BUG: 410723
FIXED-IN: 1.11
This adds a KToggleAction to PageView, which toggles RTL layout, which was previously only accessible from Configure Okular -> General.
The action is not in any toolbar, just in the action collection. Called "rtl_page_layout" and reads "Use Right to Left Reading Direction".
FEATURE: 424103
find . \( -name "*.cpp" -or -name "*.h" -or -name "*.c" -or -name "*.cc" \) -exec clang-format -i {} \;
If you reached this file doing a git blame, please see README.clang-format (added 2 commits in the future of this one)
Create a new new annotation toolbar to replace the current one as discussed in the task T8076.
Fixes:
BUG: 386578
BUG: 374728
BUG: 352310
BUG: 330518
BUG: 341914
BUG: 157289
BUG: 358057
BUG: 412767
BUG: 413595
BUG: 420462
FIXED-IN: 1.11.0
Test Plan
Before testing this revision
Delete or Temporary move aside the following files:
~/.config/okularpartrc
~/.config/okularrc
~/.local/share/kxmlgui5/okular/part.rc
~/.local/share/kxmlgui5/okular/shell.rc
Nomenclature
Actions in the main toolbar:
Quick annotations
Actions in the annotation toolbar:
Annotation actions Highlighter, Underline, Squiggle, Strike out, Typewriter,
Inline note, Popup note, Freehand line, Arrow, Straight line, Rectangle, Ellipse,
Polygon, Stamp
Annotation config actions Line width, Color, Inner color, Opacity, Font, Annotation settings
Other actions Add to Quick Annotations, Pin
Autotests
First run: annotation toolbar is not visible
Selecting Tools > Annotations shows the annotation toolbar (below the main toolbar by default)
Select an annotation > toolbar is shown
Select a quick annotation > toolbar is shown
Hide action (red cross) on the toolbar hides the toolbar
Keys 1-9,0 select the (builtin) Annotation actions (one case tested)
Keys Alt+1-9,0 select the quick annotation actions (one case tested)
No annotation action selected: Quick Annotations is enabled, Add to quick annotations is disabled, Annotation config actions are disabled, Pin is enabled
The current document is an image: Highlighter, Underline, Squiggle, Strike out are disabled (also in Quick annotations)
The current document is protected: All actions are disabled
Select annotation: the Annotation config actions are enabled and their values set to the ones for the current annotation (taken from okularpartrc)
Click an annotation action when none selected: browse mode is selected
Click the currently selected annotation action: the action is unchecked and the tool disabled (back to browse mode)
Click ESC: the currently selected annotation action is unchecked
If Pin unchecked the selected annotation is unchecked after it has be used once and we are back to Browse mode
The annotation systems works when multiple Okular tabs are open (the selected annotation is per-tab)
Manual tests
(TODO) Check that kconf_update updates the key AnnotationTools to QuickAnnotationTools in ~/.config/okularpartrc
Color icon is a format-text-color (if inline note or typewriter) or format-stroke-color for all other annotations
All actions have tooltips (some change based on the fact that the icon is enabled or not)
If a custom Line Width or Opacity is set through the Annotation Settings dialog, its value appears as a new checked action in the Line width or Opacity menu
If a custom stamp is selected through the Annotation Settings dialog, its name or filename (without path) appears as a new checked action in the Stamp menu
In Configure Okular > Annotations it is only possible to configure the quick annotations. Modifying them here updates the Quick annotations list after clicking Apply
The current document is an image: Highlighter, Underline, Squiggle, Strike out are disabled in Quick annotations
The state of Pin action is remembered across Okular launches
Selecting a quick action selects the corresponding action and loads its config values (color, line width, ...)
Setting the color and fill color works for all annotations (to be tested carefully, can be problematic for typewriter and inline note given the different internal mechanism to store the color in the settings)
Test stamp annotation (handled differently from the rest of the annotations)
Merge Request: https://invent.kde.org/graphics/okular/-/merge_requests/105
We need to use int when calculating colWidth in zoomFactorFitMode since
we also use int when calculating it in PageView::slotRelayoutPages,
otherwise the calculated numbers are veeeeeeery similar but not the same
and the algorithm gets all confused
BUGS: 420824
It's only enabled when the document supports multiple page sizes, that
at the time of writing (and since 13 years) is none
So not great to have an always disabled menu :D
The backend part (Document::supportsPageSizes) is still there, so if we
ever reintroduce a backend that supports it part of the code is there,
and probably we may want to rethink the UI so it only shows when useful,
and not being disabled without possibility of enabling it for say PDF
Summary:
This moves the Continuous option from the View menu to the
View Mode submenu. This makes the View Mode menu (a KActionMenu)
more useful in the main toolbar. Additionally, “Continuous” is explained by the context “View Mode”.
The primary intention was to give this View Mode a similar usage pattern like
the Change Colors menu (D21195), if both are added to the toolbar. See my
suggestion in Bugs 407217 and 407326.
FEATURE: 407326
Screenshot before:
{F6821917}
Screenshot now:
{F6821920}
and in the toolbar:
{F6821921}
Test Plan:
* Look into View menu and test entries
* Add View Mode menu to toolbar and test entries
Reviewers: #okular, #vdg, aacid
Spies: aacid, ngraham, okular-devel, kde-doc-english
Tags: #okular, #documentation
Differential Revision: https://phabricator.kde.org/D21196
Summary:
This replaces ToolAction by a near-drop-in replacement named ToggleActionMenu. The new annotation toolbar already uses this (D15580).
Unlike ToolAction, ToggleActionMenu inherits from KActionMenu to be more flexible.
* Menu can be set from outside, not hard coded.
* Default action for toolbar button is controllable from outside. (Theoretically, the button could trigger //anything// now.)
* KActionMenu instead of KSelectAction:
- Pluggable in other menus, thus called “Menu”.
- Doesn’t make the actions exclusive, so //any// actions can be added to the menu.
* ImplicitDefaultAction mode can choose the default action of the toolbar buttons automatically, by looking for the first checked action in the menu.
Toolbar buttons use the default action //of// this menu, not this menu itself as action.
Because the default action is configurable now, D21622 and D21635 (where we tried to fine-tune ToolAction) become obsolete.
Screenshot:
Everything like before, here with mouse_selecttool added to Tools menu to show submenu capability.
{F6884228}
Test Plan:
ToolAction replacement and ImplicitDefaultAction mode:
* Open Okular and look at toolbar button -> has correct tool selected.
* Open a document.
* Look at toolbar button menu -> Correct menu entries (like before, with ToolAction).
* Select some selection tools through shortcuts and toolbar button -> behaves correctly.
Usage as submenu:
* Add ToggleActionMenu ("mouse_selecttool") to menubar (..../kxmlgui5/okular/part.rc) -> Submenu looks correctly, has no checkbox attached and so on...
Toolbar buttons:
* Add diverse other actions to the menu -> still works as before.
* Add actions when toolbar buttons are already created -> actions are added to existing buttons.
* setDefaultAction() to some completely unrelated action. -> ToggleActionMenu does not get confused.
Reviewers: simgunz
Reviewed By: simgunz
Subscribers: aacid, ngraham, simgunz, okular-devel
Tags: #okular
Differential Revision: https://phabricator.kde.org/D21971
By waiting for the delayResizeEventTimer to trigger before starting the
test.
The test "randomly" failed before, which shows there's an actual bug in
the code, but the actual bug is "if you are moving the mouse over a
field that has a on focus action and at that very same time the
delayResizeEventTimer triggers, the action won't be executed".
That's almost impossible to reproduce in real life so i'm going to
pretend the bug is not there for all purposes