Switch to a new `input.fdopen` API & wrapper so we can keep the fds opened by `fbink_input_scan` instead of closing them to re-open them right after that...
This should hopefully help on racy zForce devices that attempt to handle power management when opening/closing the device. We know this sometimes horribly fail to re-activate the IR grid (c.f., our manual activation on resume), but this apparently could also happen here (re: #11844) because of the quick succession of open->close->open.
* Kobo: Drop a bunch of if ladder crap and switch to auto-detection of input devices via fbink_input
* Kindle: Drop an even larger bundle of crap to do the same ;p. (re: #11392)
* ExternalKeyboard: Switch to fbink_input to whitelist keyboards instead of the manual parsing of caps via its FindKeyboard class
* Input: Extended open/close wrappers to handle logging & tracking of dupe open/close calls.
As currently we only handle ReadingPaused/Resumed on suspend
and resume, no page change should happen while paused, so
there is no current issue to fix. But let's get ready for
other use cases (which may be brought in by user patches,
ie. pausing while the SkimWidget is displayed, and obviously
triggers page changes).
A typo snuck in #11492, which should've read `not type(article.mimetype) == "string" or type(article.mimetype) == "string" and not article.mimetype:find("^text/html")`. But in most cases the behavior would've been identically broken because of the same underlying issue: Wallabag mimetype is actually HTTP content-type.
Fixes#11528.
Also introduces a new setting associated with the behavior in case people have different preferences.
Previously unnoticed or changed Wallabag behavior can provide a mimetype of for example `text/html; utf-8`, which wouldn't be an exact match to `text/html`.
Fixes#11481.
Added support
1. Select only this book
2. Select all books
3. Select all books on this page
4. Deselect all books on this page
when filtering.
Ref. #11471
Can be used to inspect the state of the objects in
a running KOReader.
It can also be used to execute actions (like the ones
available to associate to a gesture) with HTTP requests
from a remote computer/devices/gadgets.
The TCP server side is provided either with a new
ZeroMQ StreamMessageQueueServer (thanks bneo99),
or with a LuaSocket based SimpleTCPServer.
Minor UIManager tweak to avoid uneeded inputevent
when such a ZeroMQ module is running.
Creating tags on memos looked like "#This is a book title" meaning only "#This" would become a Tag. Replacing spaces with underscore to be more usable so that the following tag would be created "#This_is_a_book_title"
As "global defaults" (i.e., "advanced settings" in the UI).
These were the only zones not available there, for some reason (probably
they were new and we try to avoid adding new defaults).
Fix#11142
Optimize #11087 :
1. In `isReadyToExport`, check if the ip is set. If not, then the user cannot enable xmnote export.
2. Add author field in highlights.
* 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).
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.
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).