This option saves metadata sidecar (sdr) directories not next to the book or in koreader/docsettings/, but in koreader/hashdocsettings/ using the partial md5 hash of each documents, allowing users to move, rename, and copy their documents outside of KOReader without accidentally losing their highlights/notes/progress. Included are various warnings and info to users of the benefits and drawbacks of this non-default option.
Closes#10892.
Checkboxes under TOC>Settings> allow enabling Custom TOC
and Custom hidden flows (similar to "Hide non-linear fragments"
available with some EPUBs).
Handled by a new ReaderHandmade module.
Adding and removing TOC chapters is done in PageBrowser
with long-press on a page thumbnail, and for chapters also
in the popup dialog after selecting some text in a page.
ReaderToc: add a symbol in title when the TOC is the
alternative TOC or the custom TOC.
When enabled in BookMap, both BookMap and PageBrowser get:
- alternating gray background on chapter spans
- hatched background instead of uni-gray on hidden flows.
Also, with both normal look and this alternative theme,
show some hatched overlay on thumbnails part of hidden flows.
ReaderToc: for each TOC item, have it carry its sequence/number
in that level (we do this in validateAndFixToc() where we are
already iterating all the items).
BookMap and PageBrowser instances can be stacked; when
toggling a bookmark in a lower PageBrowser and closing it,
make sure the bookmark is shown in the BookMap we get back to.
Also consider TOC and hidden flows as a thing that can be
edited and needs refreshing, so we're ready for next commits
about custom TOC and custom hidden flows.
Also update Reader footer when closing the last BookMap
or PageBrowser.
There was no real reason for having to wait.
Also avoid possible crash when a background generated
thumbnail would be displayed after other things happened.
Instead of small markers below the baseline, use
translucent vertical lines over most of the ribbon's
height to mark thumbnail rows, so we can more easily
relate chapter spans to thumbnail rows.
If originally with two-columns in page mode, and switching
to scroll mode, thumbnails generation would be slow as
the document would be rerendered for each thumbnail.
instead of doing arithmetic (ie. new_page=cur_page+1).
This makes it ready to work with custom hidden flows
where these document:getNextPage()/getPrevPage() will
be overloaded to skip pages in hidden flows.
Also fix some odd issues (page truncated or with parts
duplicated) with scrolling/page turning when at start
or end of the document.
When not provided, the cursor stays at its initial position,
which might not be the best if replacing the whole content,
where we would prefer to have it at start or end.
Namely, skip ramping when going to/from <= 2% frontlight, otherwise we just eat the delay for no good reason (1%), or it just stutters and looks bad (2%).
Fix#10970
* New menu option and filemanager filter to hide finished books #7158
The default behavior is to display the finished books (no change on
upgrade). For consistency with the two similar options, it represented
by a checkbox "Show hidden books" that is checked by default.
The implementation is straightforward, meaning that, when the option is
unchecked, each file will require a call to `filemanagerutil.getStatus`
that checks its status.
For clarity, the code uses the "finished books" expression because the
condition is relevant to the *book* metadata, while the other settings
are about *file* attributes.
This reverts commit e7e0d2edb6.
Whatever's actually going on with nightmode, this isn't it.
This was independently confirmed to behave as expected,
and the issue that prompted this was *not* fixed by this commit.
* Device: Add a `hasSeamlessWifiToggle` devcap to complement `hasWifiToggle`, to denote platforms where we can toggle WiFi without losing focus, as this has obvious UX impacts, and less obvious technical impacts on some of the NetworkMgr innards...
* Android: Mark as `!hasSeamlessWifiToggle`, as it requires losing focus to the system settings. Moreover, `turnOnWifi` returns *immediately* and we *still* run in the background during that time, for extra spiciness...
* NetworkMgr: Ensure only *one* call to `turnOnWifi` will actually go on when stuff gets re-scheduled by the `beforeWifiAction` framework.
* NetworkMgr: Ensure the `beforeWifiAction` framework will not re-schedule the same thing *ad vitam aeternam* if a previous connection attempt is still ongoing. (i.e., previously, on Android, if you backed out of the system settings, you entered the Benny Hill dimension, as NetworkMgr would keep throwing you back into the system settings ;p). This has a few implications on callbacks requested by subsequent connection attempts, though. Generally, we'll try to honor *explicitly interactive* callbacks, but `beforeWifiAction` stuff will be dropped (only the original cb is preserved). That's what prevents the aforementioned infinite loop, as the `beforeWifiAction` framework was based on the assumption that `turnOnWifi` somewhat guaranteed `isConnected` to be true on return, something which is only actually true on `hasWifiManager` platforms.
* NetworkMgr: In `prompt` mode, the above implies that the prompt will not even be shown for concurrent attempts, as it's otherwise extremely confusing (KOSync on Android being a prime example, as it has a pair of Suspend/Resume handlers, so the initial attempt trips those two because of the focus switch >_<").
* NetworkMgr: Don't attempt to kill wifi when aborting a connection attempt on `!hasSeamlessWifiToggle` (because, again, it'll break UX, and also because it might run at very awkward times (e.g., I managed to go back to KOReader *between* a FM/Reader switch at one point, which promptly caused `UIManager` to exit because there was nothing to show ;p).
* NetworkMgr: Don't drop the connectivity callback when `beforeWifiAction` is set to prompt and the target happens to use a connectivity check in its `turnOnWifi` implementation (e.g., on Kindle).
* Android: Add an `"ignore"` `beforeWifiAction` mode, that'll do nothing but schedule the connectivity check with its callback (with the intent being the system will eventually enable wifi on its own Soon(TM)). If you're already online, the callback will run immediately, obviously. If you followed the early discussions on this PR, this closely matches what happens on `!hasWifiToggle` platforms (as flagging Android that way was one of the possible approaches here).
* NetworkMgr: Bail out early in `goOnlineToRun` if `beforeWifiAction` isn't `"turn_on"`. Prompt cannot work there, and while ignore technically could, it would serve very little purpose given its intended use case.
* KOSync: Neuter the Resume/Suspend handlers early on `CloseDocument`, as this is how focus switches are handled on Android, and if `beforeWifiAction` is `turn_on` and you were offline at the time, we'd trip them because of the swap to system settings to enable wifi.
* KOSync: Allow `auto_sync` to be enabled regardless of the `beforeWifiAction` mode on `!hasSeamlessWifiToggle` platforms. Prompt is still a terrible idea, but given that `goOnlineToRun` now aborts early if the mode is not supported, it's less of a problem.
Move as much of the state tracking as possible inside VirtualKeyboard itself.
InputDialog unfortunately needs an internal tracking of this state because it needs to know about it *before* the VK is shown, so we have to keep a bit of duplication in there, although we do try much harder to keep everything in sync (at least at function call edges), and to keep the damage contained to, essentially, the toggle button's handler.
(Followup to #10803 & #10850)
* Enforce a minimal standby timer for the first standby after a resume.
* On Kobo, sleep a bit before standby.
This aims to alleviate race conditions causing visible refresh glitches on sunxi, especially when using an extremely low standby timer (i.e., below the defaults).
wpa_supplicant returns all non-ASCII SSIDs as raw bytes in the form
\x0a. We interpret these bytes as UTF-8, and make sure that all invalid
characters are replaced with a �.
Fix issue introduced by 976aaf5f: with full screen
text editor and hiding the keyboard, a tap in the
text area would show a new keyboard hiding the
buttons allowing to save/close the text editor,
getting us stuck there.
An attempt was made in the original code, but the whole thing was designed in the hope of actually switching to turbo, so it was super janky without it.
Anyway, we now actually have a sane way to set socket timeouts, so, use that, and set them very tight for now.
This is fairly critical right now, because the server is down, and the default timeouts are ~30s. That happens to be *above* the debounce threshold, so you can't even hope for that to help you. Meaning, right now, you get a 2 * 30s block on resume with auto sync. That's... Very Not Good(TM).
That becomes a single 2s one after this.
Makes more sense this way.
Re: #10828
Also clarify the UIManager "no dialogs left" message, and drop the
return value, as it's meaningless, we just want to break & return.
Assume the host system does things right otherwise.
Should be sane on Kindle
On PocketBook, who knows, but assuming the device actually suspends,
that should effectively kill our keepalive
Irrelevant for Android, as we skipped it because the wifi toggling
methods are interactive.
Fix#10823
(For reference, we *enable* wifi_was_on no matter *how* wifi is enabled,
but we only toggle it off when it's killed by a *direct* user interaction,
the intent being that if *something* non-interactive enabled wifi,
you'll probably silently need it on resume too).
As early as turnOnWifi.
Implement it on hasWifiManager platforms, preventing useless
connectivity checks to run when they're obviously never going to work
because you're out of range of your AP.
Also implemented a flag to notify the backend if the connection attempt
was interactive or not.
Right now, interactive is extremely restricted, it basically means the
menu checkmark, or a gesture.
The intent being that for stuff like the beforeWifiAction framework, we
don't want the backend to spawn extra UI.
Specifically, for hasWifiManager platforms, we no longer spawn the AP
scan list on failure unless the caller was interactive.
TL;DR: beforeWifiAction is now much less obnoxious when you're obviously
not able to connect.
onCloseDocument is way too early, if another, later onCloseDocument
handler trips a ReaderUI repaint, a new task will be scheduled, and that
one will never be cancelled, resulting in it running post-teardown,
crashing horribly.
This was for instance very easy to trigger via KOSync.
Fix#10806
MultiInputDialog does a close -> show in the same callback,
so if we don't actually keep it in sync with the actual state, we lose
the keyboard and essentially softlock the UI, which is Very Bad(TM).
NOTE: InputDialog has its own keyboard_hidden flag, and it looks...
fairly nightmarish.
This is semantically more correct, and should prevent platform-specific
weirdness if an ordering concern ever comes up (e.g., like it did for
the viewport stuff).
Make this a real boy, with a transient lipc handle.
And get rid of the insane 1s sleep on affected ReaderView paints,
because ouchy.
This is completely deprecated anyway, so this is entirely pointless,
and mainly to prevent implementation details from creeping into
reader.lua.
Re #10743
Note that this only makes faulty switches slightly less annoying: for a
stuck switch, instead of a string of page turns, you'll get a single
missed page turn on the tap that actually releases the stuck contact...
The Kindle swipe animations & physical key inversion apply *everywhere*,
so we need this accessible in the FM, too.
Move it to Navigation, which is where it already was on !Touch devices.
we use it as text anyway and test if it is the empty string also.
this fixes a crash in viewhtml when holding a selector with an empty clipboard, we try to contcate getClipboardText which is nil (on !SDL & !Android)
And add an OTM block to do a cleanup pass on existing DBs (which might take a while if you're severely affected, because we've seen reports of DBs north of 2GB).