When using an LTR language, people scan user interfaces left-to right
and top to bottom. This means that the most frequently-used controls
should be located at the top left, so people see them first.
This commit uses that principle to re-arrange the toolbar a bit, so that
after the "show/hide sidebar button" (which needs to be the left-most
item to connect it with the left sidebar), the left-most items in the
default toolbar are the zoom and view mode controls. These are
viewing-related controls, and Okular is first and foremost a viewer app.
The controls that let you interact with the document (select stuff,
annotate) are moved over to the right side of the toolbar because they
are used for secondary workflows.
The zoom buttons are also grouped together to connect them in the user's
mind.
Finally, the separator lines are re-added to disconnect the "show/hide
sidebar" button from the now-icons-only zoom buttons.
This is a useful UI element that I find myself using a lot, so quick
access is helpful. Another person just submitted a similar change (see
!689) so it would seem there is some demand for this.
In its current form, the toolbar contents would be too long if we added
it, and items would get pushed into the overflow menu. To prevent this,
let's also drop the separator lines and text from the zoom buttons.
With this MR, the sidebar can now be (if not locked):
* docked to the left or right side
* undocked and floated as an independent window
* closed with the close button in the header
BUG: 455013
There are three reasons why scrolling happens (first two cases of scrolling are actually due to
viewport transition that is triggered by annotation being traslated/created):
1. VisiblePageRect are NormalizedRect and should be represented by four values in [0, 1] interval.
Due to rounding errors caused by using QRect, they only reach the [0, 0.999] interval.
That means that right and bottom edge of the page are never visible so if annotation
is translated along the right/bottom edge viewport transition occurs (fixed in
PageView::slotRequestVisiblePixmaps)
2. For freehand line there are some constants (dX, dY) that make a line to be drawn outside
the page borders causing viewport transition. Removing these constants solves the problem (fixed
in SmoothPathEngine::event)
3. Browse mode is activated as soon as the cursor is moved outside the viewport.
Instead, we should forward the move event to the annotation which than can ignore the event (fixed
in PageView::mouseMoveEvent)
BUG: 436742
Currently, scrolling through a document using the touchpad is quite slow compared to scrolling through the standard Qt controls. This MR increases the speed of scrolling with the touchpad by removing the "magic" divider.
CCBUG: 455014
The mouse cursor wrap feature while drag-scrolling can be undesirable in some
cases; for example it can be annoying to have the cursor jump accidentally to
the distant edge of a big screen. Now users can disable this feature if they
prefer.
BUG: 421040
FIXED-IN: 22.12
Move "options_configure_color_modes" from Okular::Part::setupActions to
Okular::Part::setupViewerActions.
The color mode actions were not properly set in ViewerWidgetMode. Kile would
encounter "ASSERT failure" caused by the Q_ASSERT_X in ColorModeMenu class in
Debug mode.
Better enforce them now, so that the work to port doesn't increase over
time
Not a super fan of this for regular applications, but oh well the ship
has sailed
QLinkedList is gone from Qt6
The 1:1 port is std::list but we don't need iterator stability on
removal/insertion so just port to QList (one case to std::vector since
QList needs a copy constructor)
QLinkedList is deprecated in later Qt5 and gone in Qt6
The 1:1 port is std::list but in this cases all we ever do
is create the lists, push back to them, and pass then around
to be read, for that a QList is more than enough
Possibly introduced by commit 50d0703a.
part/pageview.cpp: In member function 'virtual void PageView::mouseReleaseEvent(QMouseEvent*)':
part/pageview.cpp:3077: error: expected '}' before 'else'
part/pageview.cpp:3069: note: to match this '{'
After fixing the porting mistake done in 78d983ee, `drawRoundedRect` can
be further simplified to not use any relative sizes anymore.
We can also assume that the code in `dviRenderer::epsf_special` was
supposed to use a constant corner radius and therefore was wrong
initially. By dropping `Qt::RelativeSize` the code might become closer
to its originally intended behavior.
Test Plan:
- No change in behavior for rounded corners of "Welcome" popup message
and "No Annotations" message in sidebar.
- Could not test DVI code path.
In 0070baaf `PageViewMessage` to display on-canvas notifications was
introduced, featuring rounded corners. Over the years, overall
preferences in the industry regarding the corner radius have changed
multiple times, with recent efforts trying to ensure a more consistent
usage in the entire UI of KDE's products.
Let's use a corner radius better matching the radius commonly used in
the current widget style, i.e. a bit less rounded, to make the message
fit in better with surrounding buttons and frames. Note that this is not
specific to Breeze, since most widget styles nowadays use a similar
corner radius. The radius is compatible with `KTextEditor::Message` too,
which is used in a similar context.
Test Plan:
- Start Okular: The "Welcome" message and the "Document Loaded"
message have a more professional look to them.
- Open the annotations sidebar: The "No Annotations" message better
fits in with the sidebar's frame.
Sune Vuorela
Nate Graham
Friedrich W. H. Kossebau
Friso Smit
Cimbali
shenleban tongying
Eugene Popov
Albert Astals Cid
Nikola Nikolic
Eduardo Cruz
George Florea Bănuș
Luis Kao
Thiago Simão
Jonathan Marten
snooxx 💤
Volker Krause