* 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 ;).
as first discussed here #11908. This PR brings the book map to non-touch devices that useDPadAsActionKeys().
Book map can be accessed from the menu or by using the following shortcut: ScreenKB + Down or Shift + Down depending on whether you use a K4 device or a kindle with keyboard respectively.
Inside the book map, a user can toggle the hamburger menu by pressing the Menu key and make any adjustment from there. ScreenKB (or Shift) + Up/Down allows it to scroll and Page turn buttons to move by whole full page turns. Back key allows user to exit the map.
With tall ButtonDialog with many rows, allows for a more
natural and readable scrolling without any truncated row
(like in Excel, we previously behave as web browsers).
ButtonTable:
- make the span and separator layout more explicite
- add some small horizontal padding when button text
is centered
When passing as 'anchor' a Geom object (ie. a widget dimen
or a ges.pos), or a function returning such an object,
a MovableContainer will be initially positionned near this
point/widget, instead of being centered on the screen.
Allow that for ButtonDialog and ButtonDialogTitle, so we
can make them behave as context menus (ie. for a titlebar
top left/right icons).
If buttons and their text would fit in a smaller width,
reduce the whole ButtonTable width.
May be used for properly sized context menus with
ButtonDialog, with the width required depending on
the translations for a language.
Make these 2 widget behave similarly, and don't rely on
ButtonTable default width for their own default width.
ButtonDialogTitle: also properly size its title.
Get rid of the doc & seqtext fields, as they are not actually used (nor
are they particularly useful, the event handler's name should be pretty
self-explanatory).
Also, tweak the key_events documentation to highlight the quirks of the
API, especially as far as array nesting is involved...
Random drive-by cleanup of the declarations of key_events & ges_events
to re-use the existing instance object (now that we know they're sane
;p) for tables with a single member (less GC pressure).
Basically:
* Use `extend` for class definitions
* Use `new` for object instantiations
That includes some minor code cleanups along the way:
* Updated `Widget`'s docs to make the semantics clearer.
* Removed `should_restrict_JIT` (it's been dead code since https://github.com/koreader/android-luajit-launcher/pull/283)
* Minor refactoring of LuaSettings/LuaData/LuaDefaults/DocSettings to behave (mostly, they are instantiated via `open` instead of `new`) like everything else and handle inheritance properly (i.e., DocSettings is now a proper LuaSettings subclass).
* Default to `WidgetContainer` instead of `InputContainer` for stuff that doesn't actually setup key/gesture events.
* Ditto for explicit `*Listener` only classes, make sure they're based on `EventListener` instead of something uselessly fancier.
* Unless absolutely necessary, do not store references in class objects, ever; only values. Instead, always store references in instances, to avoid both sneaky inheritance issues, and sneaky GC pinning of stale references.
* ReaderUI: Fix one such issue with its `active_widgets` array, with critical implications, as it essentially pinned *all* of ReaderUI's modules, including their reference to the `Document` instance (i.e., that was a big-ass leak).
* Terminal: Make sure the shell is killed on plugin teardown.
* InputText: Fix Home/End/Del physical keys to behave sensibly.
* InputContainer/WidgetContainer: If necessary, compute self.dimen at paintTo time (previously, only InputContainers did, which might have had something to do with random widgets unconcerned about input using it as a baseclass instead of WidgetContainer...).
* OverlapGroup: Compute self.dimen at *init* time, because for some reason it needs to do that, but do it directly in OverlapGroup instead of going through a weird WidgetContainer method that it was the sole user of.
* ReaderCropping: Under no circumstances should a Document instance member (here, self.bbox) risk being `nil`ed!
* Kobo: Minor code cleanups.
- ButtonTable, ButtonDialog, ButtonDialogTitle
- ConfirmBox, MultiConfirmBox, SkimToWidget
- KeyboardLayoutDialog (and initially move the dialog
down to show the title in landscape mode)
- InputText's Clipboard dialog
Also: Notification: truncate long text
* DictQuickLookup: Preserve alpha when switching dict, and scrolling
inside a dict.
* Start moving the NumberPicker alpha hack to Button itself
This makes handling flash_ui easier and saner, avoiding flickering.
* Handle the transparency hack entirely from within Button
* Murder the now unnecessary NumberPicker update_callback hack
* Tweak comments
* And the Button handling made that redundant, too
* Squish debug print
* More comment tweaks
* Reset transparency on scrolling instead of rpeserving it
* Reset alpha when switching dictionaries
* Simplify the pre/post callbakc transparency state handling
And explain why we need to care.
* Give a named reference to ButtonDialog's MovableContainer, so the Button
alpha hack behaves with it
* Document the "self.movable" convention
* Amend that comment a bit
e.g., we don't care much about MultiConfirmBox'w MpvableContainer, as
any button action will close it.
* And make SkimTo's MovableContainer accessible so that Button can grok
that it's translucent
* QuickDictLookup, ImageViewer, NumberPicker: Smarter `update` that will re-use most of the widget's layout instead of re-instantiating all the things.
* SpinWidget/DoubleSpinWidget: The NumberPicker change above renders a hack to preserve alpha on these widgets almost unnecessary. Also fixed said hack to also apply to the center, value button.
* Button: Don't re-instantiate the frame in setText/setIcon when unnecessary (e.g., no change at all, or no layout change).
* Button: Add a refresh method that repaints and refreshes a *specific* Button (provided it's been painted once) all on its lonesome.
* ConfigDialog: Free everything that's going to be re-instatiated on update
* A few more post #7118 fixes:
* SkimTo: Always flag the chapter nav buttons as vsync
* Button: Fix the highlight on rounded buttons when vsync is enabled (e.g., it's now entirely visible, instead of showing a weird inverted corner glitch).
* Some more heuristic tweaks in Menu/TouchMenu/Button/IconButton
* ButtonTable: fix the annoying rounding issue I'd noticed in #7054 ;).
* Enable dithering in TextBoxWidget (e.g., in the Wikipedia full view). This involved moving the HW dithering align fixup to base, where it always ought to have been ;).
* Switch a few widgets that were using "partial" on close to "ui", or, more rarely, "flashui". The intent being to limit "partial" purely to the Reader, because it has a latency cost when mixed with other refreshes, which happens often enough in UI ;).
* Minor documentation tweaks around UIManager's `setDirty` to reflect that change.
* ReaderFooter: Force a footer repaint on resume if it is visible (otherwise, just update it).
* ReaderBookmark: In the same vein, don't repaint an invisible footer on bookmark count changes.
This is a quick exploration into how the new Device:hasFewKeys() method could work to make things more usable on very limited devices.
In the reader, the right is repurposed to open the menu. Left in turn closes it.
The same principle is applied to ButtonDialog. This means you can select anything in principle, but once you go right you can't go back.
References <https://github.com/koreader/koreader/issues/4029>.
This makes button heights similar in all uses of ButtonTable.
It depended on how the ButtonTable was used in each widget
(previously, first and last row may have different sizes than
the others).
buttontable.lua: more even buttons height whether zero_sep or not
framecontainer.lua: added padding_top/bottom/left/right (similar to
what was done for iconbutton)
The following widgets have been adapted for this, with some
additional fixes:
buttondialog.lua
buttondialogtitle.lua: wider title with adequate padding
confirmbox.lua + multiconfirmbox.lua: dismissable via tap outside
inputdialog.lua + multiinputdialog.lua: more even vertical padding between elements
imageviewer.lua
textviewer.lua
datewidget.lua
timewidget.lua
Additionaly: frontlightwidget.lua: fixed width of progress bar that
was exceeding window width since the Size scaling adjustements
More closely matches native behavior on REAGL devices.
Closing those widgets should still trigger a partial refresh though,
because we usually get back to the reader, and text, so we want REAGL
;).
This is a larger clean-up of the refresh situation.
The general shift is that refreshes are now mainly triggered by
the (top-level) widgets when they get shown or closed via UIManager.
All refreshes for the widgets when they are in use were handled by
themselves before. This adds the case of showing/closing.
It is the desired result of not having UIManager:show()/:close()
do (full screen) refreshes on its own.
This is a major overhaul of the hardware abstraction layer.
A few notes:
General platform distinction happens in
frontend/device.lua
which will delegate everything else to
frontend/device/<platform_name>/device.lua
which should extend
frontend/device/generic/device.lua
Screen handling is implemented in
frontend/device/screen.lua
which includes the *functionality* to support device specifics.
Actually setting up the device specific functionality, however,
is done in the device specific setup code in the relevant
device.lua file.
The same goes for input handling.
colors were a mixture of 4bpp integers (0=white, 15=black) and
fractional blackness levels (0=white, 1.0=black) before. This is
now unified to use the color specification of the Blitbuffer API.
- Refactor FileDialog and HightlightDialog into ButtonDialog
- Create a new ButtonDialog when a file in the History dialog is hold,
offering an option to delete the history entry.
