The bounding rect is *visual* and it can happen that we have
invisible text and thus the algorithm will get super confused
because there will be text items that are outside the text area
There used to be a Q_ASSERT_X that was triggered when a widget was requested
with something else than a QToolBar as parent widget.
However, when the ToggleActionMenu is added to a QMenu,
createWidget() is called with the QMenu as parent.
This case was missed to be tested, but occurs when the toolbar
is detached/moved by the user.
PageView::slotScrollUp/Down() queried the size of the scrollbar instead of the viewport,
which has no obvious reason and doesn’t work when scrollbars are not there.
Probably the scrollbar size was thought to be more robust
in times when PageView had overshoot enabled.
Also fixes code documentation for these methods,
and removes another spaghetti feature where Continuous mode was queried
in an `if` branch before the one where it is relevant.
BUG: 421822
There's always at least one tab since an okularpart is created at startup.
The supported minetypes are always read from this so fileFormats is never called.
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.