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.
poire-z
NiLuJe
François Gannaz
Benoit Pierre
hius07
hrdl
ElimGarak1
hugleo
Serge Baranov
Frans de Jonge
Wim de With
dependabot[bot]