Disable bugprone-suspicious-include since it's triggered by the moc
includes
Disable bugprone-reserved-identifier since it's triggered by all our
_OKULAR defines, and yes even if the spec says that underscore is
reserved, are we going to be that unlucky that the library decides to
start using _OKULAR ? not probably
Add two TODOs for the future to make NormalizedRect/Point faster
Silence a warning about a quick moving QString if we make it non const
Silence a uchar vs char warning that is in decades old code so
experience seems to suggest it's ok.
If not, open did not succeed and the callers (for example open document
X in page A) would like to know so they don't have to do the "change to
part A" part.
BUGS: 429924
`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
If a symlink points to another file, we should use that file as
canonical source for bookmarks, it doesn't make sense to have two
different sets of bookmarks for two paths that are essentially the same
file
BUGS: 424340
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)
The problem was that the JS checker for the field format was using the
willCommit property of event and we don't define it so the JS
interpreter was going "ok nope, out of here" and the field didn't get edited.
I've read the willCommit definition in js_api_reference.pdf for almost
30 minutes, and even it's just 3 lines i don't think i understand it,
but i think that returning true is "safer", i.e. says that this event is
going to actually change the field, which as far as i can see it's what
we always do
BUGS: 421508
Previously it just said, "Multiple" for multi-page-size documents.
Now it will tell you the most common page size on the "Properties"
tab, and display a full table of all page sizes in a new "Page Sizes" tab.
For documents with only a single page size, there are no changes.
Currently when a document has multiple page sizes, the Properties dialog
does not show the "Page Size" field at all. This MR populates the field
with the string "Multiple" for documents with multiple page sizes.
If from processFormatAction we call setAppearanceText,
we need to call setAppearanceText from outside too, otherwise when the
formatting action doesn't create a different text we still show the old
old value
CCBUGS: 418445
It happens that sometimes the hypen is actually "part of the word" like
in one-third, so if there's one- at the end of a line
and third at the beginning of the next, we should still match and not
force the user to type onethird, even we will also match onethird since
there's no way to know if "hyphen at end of line" is supposed to be part
of the word or not
BUGS: 418520
This adds utility functions to util to work with QLocale
for formatting and Number handling.
At least until we support AFNumber_Keystroke to restrict
what a user enters in Number input fields it is good
behavior to expect the user to enter Numbers in the system's
Locale.
AFNumber_Format is new for formatting and uses the
Locale util functions.
Partial updates trigger when the page is taking "too much" to render (>
500 ms).
When this happens we store a pixmap for the page, this meant that
Page::hasPixmap returned true, so when moving the viewport around we
would think that that page was already rendered, and thus needed no
rendering so we didn't add it to the list of requested pixmaps.
Then on document when seeing the new list of requested pixmaps we would
go and check and say "oh there's one request going on that we don't want
anymore, let's cancel it", so we would cancel the page that we actually
wanted (and clear the partial pixmap)
Then on the next scroll we would realize we did not have that page
pixmap and then request it again which since it's the current page would
immediately stop all other renders and start this one.
Then we would get a temporary pixmap and the loop of cancellations and
requesting again would keep happening as long as the user moved the
viewport.
We fix that my making hasPixmap return false if the pixmap we have is a
partial one, because that's what the function meant "forever" until we
recently introduced partial updates so all the calls to hasPixmap
actually mean "hasNonPartialPixmap"
BUGS: 418086
