- standalone: no other dependencies than Python (>= 3.7) and adb
(Android >= 4.3 [Jelly Bean])
- filter KOReader's traces, and other processes chatter about KOReader
(e.g. mentions of its application ID or PID)
- show time, PID, TID (when different), tag, priority, and message
- only parse the log (don't rely on `adb shell` commands)
- can be used as a filter, including on its own (uncolored) output
- we can simplify instructions to users when asking for detailed logs
Why not use pidcat?
- project is unmaintained
- does not support Python 3 (need at least one extra patch)
- mangle long lines by wrapping them, even when not outputting to a terminal,
which is a big no-no, IMHO (as it break searching, copy pasting, etc…)
MuPDF's own stylesheet is incomplete, and doesn't specify that
a few common (and uncommon) elements are display:block, so it
would consider them inline, and render them badly (MuPDF also
doesn't handle well <BR/> inside inline elements, so this
fixes <br/> ones in these elements).
Fix this in HtmlBoxWidget so it solves any issue in HTML
dict and popup footnote.
For popup footnotes, also include crengine internal block
elements, as we may indeed get them in the HTML content.
When a profile changes a few settings (ie. font), a few notifications
may be stacked, before the single rerendering happens. If that rendering
takes some time, the notifications' timeout may close them as soon
as it is done, before they get a chance to be painted/refreshed.
So, delay a bit more that rerendering to be sure the notifications
are shown.
* FocusManager: Fix `focus_flags` check in `moveFocusTo` (0 is truthy in Lua, can't do AND checks like in C ;).)
* FileManager+FileChooser: Pass our custom title bar directly to FileChooser (which also means we can now use FC's FocusManager layout directly).
* FileChooser/Menu: Get rid of the weird `outer_title_bar` hack, and simply take a `custom_title_bar` pointer to an actual TitleBar instance instead.
* FileManager/Menu/ListMenu/CoverMenu: Fix content height computations in `_recalculateDimen` (all the non-FM cases were including an old and now unused padding value, `self.header_padding`, leading to more blank space at the bottom than necessary, and, worse, leading to different item heights between FM views, possibly leading to unnecessary thumbnail scaling !)
* ButtonDialog: Proper focus management when the ButtonTable is wrapped in a ScrollableContainer.
* ConfigDialog: Implement a stupid workaround for a weird FocusManager issue when going back from `[⋮]` buttons.
* ConfigDialog: Don't move the visual focus in `update` (i.e., we use `NOT_FOCUS` now that it works as intended).
* DictQuickLookup: Ensures the `Menu` key bind does the exact same thing as the hamburger icon.
* DictQuickLookup: Ensure we refocus after having mangled the FocusManager layout (prevents an old focus highlight from lingering on the wrong button).
* FileChooser: Stop flagging it as no_title, because it is *never* without a title. (This behavior was a remnant of the previous FM-specific title bar hacks, which are no longer a thing).
* FileChooser: Stop calling `mergeTitleBarIntoLayout` twice in `updateItems`. We already call Menu's, which handles it. (Prevents the title bar from being added twice to the FocusManager layout).
* FocusManager: Relax the `Unfocus` checks in `moveFocusTo` to ensure we *always* unfocus something (if unfocusing was requested), even if we have to blast the whole widget tree to do so. This ensures callers that mangle self.layout can expect things to work after calling it regardless of how borked the current focus is.
* FocusManager: Allow passing `focus_flags` to `refocusWidget`, so that it can be forwarded to the internal `moveFocusTo` call.
* FocusManager: The above also allows us to enforce a default that ensures we do *not* send a Focus event on Touch devices, even if they have the hasDPad devcap. This essentially restores the previous/current behavior of not showing the visual feedback from such focus "events" sent programmatically, given the `focus_flags` check fix at the root of this PR ;).
* InputDialog: Fix numerous issues relating to double/ghost instances of both InputText and VirtualKeyboard, ensuring we only ever have a single InputText & VK instance live.
* InputDialog: Make sure every way we have of hiding the VK play nice together, especially when the `toggleKeyboard` button (shown w/ `add_nav_bar`) is at play. And doubly so when we're `fullscreen`, as hiding the VK implies resizing the widget.
* InputText: Make sure we're flagged as in-focus when tapping inside the text field.
* InputText: Make sure we don't attempt to show an already-visible VK in the custom `hasDPad` `onFocus` handler.
* Menu: Get rid of an old and no longer used (nor meaningful) hack in `onFocus` about the initial/programmatically-sent Focus event.
* Menu: Get rid of the unused `header_padding` field mentioned earlier in the FM/FC fixes.
* Menu: Use `FOCUS_ONLY_ON_NT` in the explicit `moveFocusTo` call in `updatePageInfo`, so as to keep the current behavior of not showing the visual feedback of this focus on Touch devices.
* Menu: Make sure *all* the `moveFocusTo` calls are gated behind the `hasDPad` devcap (previously, that was only the case for `updatePageInfo`, but not `mergeTitleBarIntoLayout` (which is called by `updateItems`).
* MultiInputDialog: Actively get rid of the InputText & VK instances from the base class's constructor that we do not use.
* MultiInputDialog: Ensure the FocusManager layout is *slightly* less broken (password fields can still be a bit weird, though).
* TextViewer: Get rid of the unfocus -> layout mangling -> refocus hack now that `refocusWidget` handles this case sanely.
* VirtualKeyboard: Notify our parent InputDialog when we get closed, so it can act accordingly (e.g., resize itself when `fullscreen`).
* ScrollableContainer: Implement the necessary machinery for focus handling inside ButtonDialog (specifically, when scrolling via PgUp/PgDwn).
* TextEditor: Given the above fixes, the plugin is no longer disabled on non-touch devices.
* ReaderBookMark: Make sure we request a full refresh when closing the "Edit note" dialog, as CRe highlights may extend past its dimensions, and if it's closed separately from VK, the refresh would have been limited to its own dimensions, leaving a neat InputDialog-sized hole in the highlights ;).
This shall fix#12271
Use $SHELL env-variable if available. (thanks to @Frenzie)
Use a read line wrapper (either rlfe or rlwrap) if available so that dash can be used as interactive shell.
In font selection menus, ask creengine for italic versions
of fonts if there's no regular version to preview.
Also prevents a crash when a font can't be previewed in
the font family menu.
Use `ANDROID_NAME` for last part so setting it as an environment
variable to something like `dev` allows for a stable APK name
across different revisions.
setIcon recreates the frame without preserving the current frame's
invert status (which is arguably a bug, but button is so ubuquitous that
I dare not touch that behavior...).
So, instead, rely on the rarely used preselect flag to preserve it.
When footnotes are displayed as "popups", they're displayed over ReaderUI
in a BottomContainer, so they pretty much always cover the footer ;).
(i.e., they're really really not popups *at all* :D).
This prevents spurious status bar auto-refreshes.
Re #12323
Factorize (options handling, target setup, …), add explicit
Android targets (`android-arm`, `android-arm64`, etc…).
build:
- support `--no-build` / `-b`: only run setup phase
check: simplify implementation (re-use `.ci/check.sh`)
cov & test:
- forward to makefile rules (no need to guess install directory)
- support `--no-build` / `-b`: use existing build
log:
- drop the target argument (since only Android is supported anyway)
prompt & wbuilder:
- forward to makefile rules (no need to guess install directory)
- support `--no-build` / `-b`: use existing build
release:
- support `--no-build` / `-b`: use existing build
run:
- forward to makefile rules (no need to guess install directory)
- correctly support relative arguments, and whitespace in arguments
- drop support for catchsegv: Glibc 2.35 (2022) dropped catchsegv and
associated `libSegFault.so` shared library
- drop support for nemiver debugger: project is dead, last release
was 8 years ago, repo is archived, and package has been dropped
from newer Debian / Ubuntu releases
- support running an APK passed as argument when using `android` target
- rename short `-d`, `-h`, and `-w` options to `-D`, `-H` and `-W`
respectively (to avoid conflicts with standard options)
- drop support for `-p` / `--graph` argument: code moved to a dedicated
wrapper script (`tools/graph_memory.sh`) that can be used with the new
`-w` / `--wrap` argument: `./kodev run -w tools/graph_memory.sh …`
- drop `--tui` argument when using GDB: said TUI does not cohabit well
with KOReader console outputs (and cgdb is better fancy TUI anyway)
I don't even remember how badly things broke (at least on old devices) without it, despite it making absolutely no sense at all (state-extended just flips a global that dictates whether some things get flagged as wakeup sources or not).
So, don't rock the boat too much: we don't remove it, but instead of using a sleep, we use a task deadline instead, which ensures we'll keep processing input events in the right order in the meantime. We'll already have neutered input by this point, so we'll only process power events anyway.
That means that the only iffy things are potentially *when* and *where* we have to potentially cancel that task. Resume makes sense, of course, and we log an info message to make the log flow clear; but we also do so in suspend... just in case. With a warning log because that probably indicates something fishy went on.
Also cleanup the comments while I'm there, and actually rewrite the wakeup_count stuff properly so it could actually theoretically be used if ntx kernels were actually reliable. Spoiler alert: they're not, this is still horribly broken on at least Mk < 7. Works just fine on a Forma, though, so, yay.
Fix#12325
Input events from ImageViewer can be caught between it clearing an old
ImageWidget & instantiating a new one, but before the new one has had a
chance to actually render anything.
Fix#12327
