GitLab

Okular's sidebar vertical view chooser toolbar suffers from a few issues:

* It's a nonstandard UI not used for category choosers in other pieces of KDE software,
  and not used in other FOSS document readers
* What is shown and what is hidden is simultaneously too configurable while still not
  offering the desirable UI common to other programs (i.e. no visible category chooser,
  but a sidebar capable of displaying thumbnails, table of contents, search results, etc.)
* With labels on it takes up quite a bit of horizontal space, while with labels off, the
  categories are less than clear
* UX is kind of clunky with nonstandard behaviors (e.g. clicking on the current category
  to hide that category's view while keeping the view chooser visible, showing mostly
  disabled items)
* It's made with custom painting code, which reduces maintainability and introduces bugs
  (e.g. https://bugs.kde.org/show_bug.cgi?id=408190)

This patch removes the vertical category chooser entirely and replaces it with a tabbed
view on the top of the sidebar itself. The tabs are icons-only and have large icons. A
button is added on the left side of the default toolbar to quickly hide or show the
sidebar. In order to make room for the new button, the Previous and Next buttons on the
toolbar are removed, as previous/next buttons are already present on the Page Bar on the
bottom of the window so there's no need to duplicate this functionality. This improves
the UX, fixes a variety of bugs, and deletes a lot of custom code of dubious long-term
maintainability.

![vokoscreenNG-2020-04-16_13-29-24](https://invent.kde.org/graphics/okular/uploads/a1f96a315b69282df51de9993b1befaf/vokoscreenNG-2020-04-16_13-29-24.webm)

BUG: 213508

BUG: 334441

BUG: 344599

BUG: 408190

CCBUG: 335189

FIXED-IN: 1.11.0

CHANGELOG: The sidebar can now be easily shown or hidden with a toolbar button, and the category chooser no longer takes up so much space

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

It was introduced in 51b90ecd together
with kinetic scrolling, but people do not like it.

BUGS: 421482

When filtering the items in the contents panel, we start iterating over
them using rootIndex() to get all the children, don't do the same loop
for each and every item, one go is enough.

Also only use a regular expression if the regularExpression option is
enabled, otherwise just use string operations, the latter is always
faster. With this change, both regex and non-regex search are faster.

BUG: 421469

When using Okular as previewer in PDFTex workflow, preparing beamer slides,
the following usability hell occurred:

* LaTex/Beamer slides should be compiled to PDF with metadata "StartFullScreen"
* But while editing, on every PDF change/and reload, the user gets a modal popup
  "The document requested to be launched in presentation mode." "Do you want to allow it?"

BUG: 361740

poppler 0.88 is crashy when using the signatures() method.

Use poppler's own version defines to check for 0.89 (since there's no
new api added in 0.89 we can't check it like the others)

BUGS: 421468

Needs poppler 0.88, we "pretend" the belong to page 0 since in Okular
core there's no concept of having a signature that doesn't belong to any
page

BUGS: 415199

When processing the <a> elements, store in two maps those that contain
an href="#Something" and those with name="Something" then once we've
processed them all, go over the first map trying to find itself in the
second

BUGS: 421163

(cherry picked from commit 3d148bd5)

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

BUGS: 421004

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

BUG: 420492
FIXED-IN: 1.10.1

This just removes the smooth mouse wheel scrolling, fixing that problem.

Disabled by default

BUG: 419096

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

The whole file is a mess, but in particular this was making a warning so
let's fix it

Generate presentation drawing tool icons in a custom QIconEngine, so checkboxes can be sharp on hidpi

The checkboxes in the drawing tool icons in the presentation toolbar were not sharp on hiDPI, this fixes it.

The toolbar buttons are QActions with QIcons, and the icons were created from 25x25 pixmaps. That is usually smaller than the toolbar’s icon size, so the icons had a nice size. But at hiDPI, the icons were scaled up, so the checkmarks looked blurry.

Now the icons are generated in the correct resolution on the fly, because the painting code from ColorAction::setColor() is moved to a custom QIconEngine inside ColorAction.

Otherwise when CI gets a new enough poppler it'll start failing