[fix, UX] Fix slow keyboard when double tap not disabled
When double tap is not disabled (only ensured in ReaderRolling),
repeated key hits were slowed down by it. This ensures
Input widgets that temporarily overrides it to be disabled
are satisfied.
Multiswipes consisting of mixed straight and diagonal strokes are not dependable and too easy to mess up, but making them mutually exclusive seems to work out quite well.
Updated for https://github.com/koreader/koreader/pull/4691
Also the assert.is_same() argument order was wrong.
The first argument is expected, the second the real-life result.
Otherwise the error message in case of failure is misleading.
When multiswipes are enabled, this fixes the long-standing complaint that swiping to open the menu could unintentionally trigger some light panning. With the introduction of multiswipes, this problem has become more noticeable.
Before multiswipes and the gesture manager this was impractical on touch-only devices, but no more!
Also includes some minor textual clarifications on some of the settings.
By scrolling last page a little bit further.
Also fix a few other scroll mode issues, all related
to doc_height not being updated (eg, in the middle of
a book, and doubling the font size, one would not
be able to turn pages and read the 2nd half of the
book...)
The idea of looking for highlights 1 page before and after
was not working when you have multiple small pages, and
some scroll mode view was actually showing 3 or 4 pages.
So, rework that by using absolute positions when looking
for highlights present in the scrolled view.
Includes:
- Fix text selection in some tables
- Add known HTML attributes to avoid cache issues
- Make existing context.AddLine() and pb_flag clearer
cre.cpp:
- gotoPos(): allow scrolling after end of document
(to avoid not seeing the last line of a document
that would be hidden by the footer bar)
Reported by @poire-z, cf. https://github.com/koreader/koreader/pull/4640#issuecomment-466544922
Apparently it's natural for me to make the second swipe slightly longer than the first, so I never noticed a logic issue. I did notice that it seemed slightly harder to make 4-swipe multiswipes than I expected it to be, but those are not necessarily easy gestures to make.
The problem was that I needed to prevent obviously silly gestures like west west west east. In ignoring such duplication, what I accidentally did was to ignore any further movement west after the first multiswipe direction was detected, meaning that the following swipe east could still end up as a relatively western movement overall.
By simply updating the current multiswipe slot in case of the same direction, both problems are prevented. We'll never get the same direction twice, and X moves over to where it's supposed to be on the left.