- TextWidget: avoid crash with small max_width (could happen
when opening menu on a small emulator window)
- TextWidget: avoid crash if re-used after :free()
- ReaderHighlight:clear(): fix possible crash when
scheduled and run after document closed
- DictQuickLookup: minor canSearch() tweak ('selected_text'
is normally available only on multiple words selection,
but is currently available on single word selection thanks
to some unrelated side effect)
Whith the new font size step of 0.5 (46a2d9c), the gesture
for increasing or decreasing font size would change the
size by only half of the given value.
* Tear down FM instances properly
* Don't manhandle ReaderUI too much, and document when the tests do
actively broken shit, like bypassing safeties to open two // ReaderUI
instances.
We're now more careful about this, so, I suppose weird timings may mean
we might be trying to access a nil here.
Fix#7706
Guard a few other similar constructs
FFI finalizers can fire in unspecified orders, but for MuPDF,
we need to ensure that the context is the *very* last thing that get
destroyed.
As such, we need to make sure we close open documents properly on our
end, first.
This prevents potential crashes while switchign to USBMS inside an open
document handled by MuPDF.
Fix#7428
Namely, instead of making it lower priority than readerhighlight and
hoping for the best, make it higher priority, as it should (ReaderFooter
itself is *above* Reader, after all), with a sane set of fallthroughs:
* No footer
* No hold-to-skim
* Held outside the footer (but inside the footer tap zone)
This made the crap workaround from #7466 unnecessary, and actually fixes
the behavior in PDFs (because readerhighlight will match the *physical*
page, which may include off-screen content) and ePubs w/r eclaim bar
height (in which case, there's actual content behind the footer that
readerhighlight could have matched on).
Fix#7697
Searches for a string in the edited text.
Available in the Text editor and other input dialogs with the navigation bar enabled.
Find first searches from the beginning of the text.
Find next searches from the next to cursor position, used for continious search.
By now, the Search input window is closed after the search. You need to press the Find button again for continious search, the search string is kept in the input.
Is it better to keep the dialog open for the comfortable continious search? And close it with the Cancel only?
Case insensitive. Cursor jumps to the beginning of the found string.
Notifications are shown for better results visibility.
Unfortunately, violated our standartization to "search", couldn't invent better short wordings.
To avoid a few log lines on all platforms:
```
ffi.load: SDL2
ffi.load (warning): libSDL2.so: cannot open shared object file: No such file or directory
ffi.load: libSDL2-2.0.so
ffi.load (warning): libSDL2-2.0.so: cannot open shared object file: No such file or directory
ffi.load: libSDL2-2.0.so.0
ffi.load (warning): libSDL2-2.0.so.0: cannot open shared object file: No such file or directory
```
We've managed to trip a few of those on dimen fields post-init but
pre-paintTo in a few weird coner-cases, a point at which dimen is often
nil.
ConfigDialog: Deal with that very thing in update()
Fix#7656
A dotted line joining the ToC entry text to the
page number may make it easier to use.
(This replaces the menu item separator from d879062e.)
Also fix baselines aligment, which could be a bit off.
* FileManager/ReaderUI: Clarify the current instance accessor
Make it clearer that we actually store it in a *module/class* member, not an *instance* member.
Also, warn if there's a close/open mismatch.
Use a table & table.concat instead of individual concats.
And then use that same table for every hash-related operation.
(Nothing else uses the configurable hash function, otherwise I'd have
limited the table shenanigans to the function itself).
* Allow doing away with CacheItem
Now that we have working FFI finalizers on BBs, it's mostly useless overhead.
We only keep it for DocCache, because it's slightly larger, and memory pressure might put us in a do or die situation where waiting for the GC might mean an OOM kill.
* Expose's LRU slot-only mode
And use it for CatalogCache, which doesn't care about storage space
* Make GlyphCache slots only (storage space is insignificant here, it was
always going to be evicted by running out of slots).
* More informative warning when we chop the cache in half
* Neuter timekeeping when statistics are disabled
Saves a few syscalls ;).
* Port to ffi/lru
Only a tiny bit of it actually requires any sort of LRU logic, so it's fairly painless.
* Release the cache on close
* Use string.buffer to serialize function arguments
Ought to be faster than the custom approach ;).
(Still requires wrapping them in a table, though).
It's much less human-readable, but then again, this doesn't need to be :).
