Don't cleanup input text as much when entered manually
(or when it's sane) than when coming from book text
selection.
This may allow looking up words like "-suffix", or
do more precise Wikipedia queries.
Brainfart from 6162c287e8
Forgot to zap the original UIManager:show(), so we were stacking two
identical widgets on top of each other, which obviously affected alpha.
Re #7029
- Rework widget layout to avoid implicit (and wrong)
sizing, using proper padding/margins and correct
measurements of components.
- Adjust lookup word font size so it's not smaller
than the definition.
- Tweak small window positionning: keep it centered
if possible, only move it to keep the highlighted
word shown when we can.
- Large window: adjust to screen size correctly,
leaving room for footer.
- Always have a "Close" button at bottom right.
Former always displayed button "Follow link" will
be added as a 3rd row in the rare case we select
a word in a link.
- Replace "tap on lookup word to edit and redo the
query" with an icon on the right: tap on it to
edit the queries word, long-press to edit the
current result word. Only close the current dict
window when lookup is launched.
- Remove feature "tap on title to set current dict
as the default dict for this document", as it didn't
really work, and it was bad UX.
If interrupted quickly just after lookup launch, don't
display anything (this might help avoiding refreshes
and the need to dismiss after accidental long-press
when manipulating the device).
- InfoMessage: add an option show_delay.
- MovableContainer: avoid possible crash when
not yet painted.
- ReaderDictionary: use show_delay=0.5 instead of
scheduleIn(0.5n...) (a5b133da) as we need the
InfoWidget to be known to UIManager to catch tap
and allow interrupting lookups properly.
- ReaderDictionary: rework handling of no_refresh_on_close
(6162c287) with proper regions comparisons
Drop the use of crengine's getWordFromPosition() which
is a bit unreliable: it may returns wrong coordinates,
or words from far away in the book (ie. when holding
in the margins).
Rely only on the robust getTextFromPositions() that
we already use for multi words selection.
Having good coordinates allows refreshing a smaller region
(the higlighted word, or the 2 lines if hyphenated).
* Modernize jit syntax
It's built-in, no need for a require anymore.
* Flag Android should_restrict_JIT again
It's mildly helpful at putting off the inevitable.
(very, very, very, very mildly).
* Bump android-luajit-launcher
https://github.com/koreader/android-luajit-launcher/pull/281
That way images can be made to work in a more generic, portable manner, such as:
```
return function(html, dict_path)
html = html:gsub('<rref[^>]*>([^<]*%.jpg)</rref>', '<img src="'..dict_path..'res/%1">')
return html
end
```
Cf. <https://github.com/koreader/koreader/issues/6056>.
* Don't paint invisible background-colored rounded corners
Made obvious when testing #7042
* Only enforce a highlight radius on buttons that don't already set a
custom one ;).
(Mostly, square buttons with a 0 radius ^^).
ffi/blitbuffer already handles radius being nil, which suits us just fine
:)
Avoid opening two connections in //, by feeding the current connection
to saveSetting, like we were already doing for loadSettings...
It somehow worked just fine on Kobo/Emu, but blew up in fun and
interesting ways on Kindle, probably because of the Fuse proxy.
It was still pretty dumb nonetheless.
