According to https://bugs.kde.org/show_bug.cgi?id=437334
the cursor position is not necessarily known on Wayland.
That would trigger the Q_ASSERT_X, so this patch removes
it. This does not solve the problem that we can not wrap
the cursor, but it prevents crashing Okular if using the
debug build on Wayland. You’re reading rectangular text.
BUG: 437334
CCBUG: 439471
When the annotation is unchecked the previous mouse mode is restored.
The slot slotMouseNormalToggled is changed back to its original version
of slotSetMouseNormal given that we needed to pass the checked state
only to detach the annotations, and we do it in the lambda now.
BUG: 398108
BUG: 437377
FIXED-IN: 21.08
From a glimpse at the khelpcenter code, I think it indexes all the html
pages in a manual, then finds the requested page by searching for the filename
(I am not 100% sure, though), for example either of these two urls work:
help:/okular/index.html#adding_digital_signatures
help:/okular/signatures.html#adding_digital_signatures
but when falling back to opening the manual at docs.kde.org in a web browser
that indexing isn't available, so we have to be a bit more precise with the
urls, so use the second url.
(cherry picked from commit df02881611)
From a glimpse at the khelpcenter code, I think it indexes all the html
pages in a manual, then finds the requested page by searching for the filename
(I am not 100% sure, though), for example either of these two urls work:
help:/okular/index.html#adding_digital_signatures
help:/okular/signatures.html#adding_digital_signatures
but when falling back to opening the manual at docs.kde.org in a web browser
that indexing isn't available, so we have to be a bit more precise with the
urls, so use the second url.
Adobe Reader doesn't do it, and with reason, because otherwise we end up
with:
* Run focus in script
* script shows alert()
* field loses focus and gains it again once the alert() is closed
* infinite loop
BUGS: 436990
Adobe Reader doesn't do it and if we do it can end up crashing because
we end up running two focusout actions in parallel and our script system
is not prepared for that:
Scenario:
* Tab out of a field
* Script for that focusout runs
* focus goes to next field
* script for that focusout shows an alert()
* second focusout script for that field runs while the first is running
* bad stuff
BUGS: 435833
Implemented using a ColorModeMenu class,
derived from ToggleActionMenu (derived from KActionMenu),
as a child object of PageView.
* KToggleAction for every color mode, allows to set shortcuts for every mode.
Color mode actions have icons.
* KToggleAction for normal colors mode.
* ToggleActionMenu containing all color mode actions.
If triggered, toggles color mode between normal colors and last change colors mode.
"Toggle Change Colors" is replaced by "Change Colors", which is actually a toggle action.
BUG: 407217
BUG: 437755
A limitation of the current implementation is that when the quick annotation tools are modified by the user, the first quick annotation tool is selected. This because the order of the quick annotation tools may be changed and some tools may have been deleted.
This prevents undefined states when the currently selected quick annotation is modified or deleted in the annotation settings.
BUG: 426026
FIXED-IN: 21.08
* Remove the ImplicitDefaultAction intelligence, so ToggleActionMenu is
not more than a KActionMenu with setDefaultAction().
* Instead, reset the default action when it gets removed from the menu().
This is done by filtering QActionEvent from menu().
* Add an autotest for ToggleActionMenu.
This replaces prior efforts to fix problems in ToggleActionMenu
in !245 and !254, following the discussion on the virtual meeting
at 2021-02-26.
6b26a2b4b and 1786e6c99 have already ported PageView and
AnnotationActionHandler to the simplified interface.
The coordinates in Viewport.rePos are normalized on the full page. In
two functions within pageview.cpp, these were treated as coordinates on
the cropped page.
CCBUG: 198427
This partially fixes the bug 198427 in the case that the cropping of the
target pages (and the pages around the target) is known at the time the
link is clicked. That is, it works if
- One uses 'Trim To Selection'
- One uses 'Trim To Margin' and has already viewed at the target
page(s).
In the case that the cropping of the page at the target is unknown, we
still end up at the wrong position.
