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
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
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
Summary:
This moves the Continuous option from the View menu to the
View Mode submenu. This makes the View Mode menu (a KActionMenu)
more useful in the main toolbar. Additionally, “Continuous” is explained by the context “View Mode”.
The primary intention was to give this View Mode a similar usage pattern like
the Change Colors menu (D21195), if both are added to the toolbar. See my
suggestion in Bugs 407217 and 407326.
FEATURE: 407326
Screenshot before:
{F6821917}
Screenshot now:
{F6821920}
and in the toolbar:
{F6821921}
Test Plan:
* Look into View menu and test entries
* Add View Mode menu to toolbar and test entries
Reviewers: #okular, #vdg, aacid
Spies: aacid, ngraham, okular-devel, kde-doc-english
Tags: #okular, #documentation
Differential Revision: https://phabricator.kde.org/D21196
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