Repository navigation
Release 1.1.49 (versionCode 52) - #137
Merged
Merged
Conversation
On a phone whose WebView draws the page under the system bars (WebView 140 and up, which Play keeps current), the clock, signal and battery drew near-black on the dark ZenNotes theme, and the navigation buttons did the same. capacitor.config.ts asks the StatusBar plugin for light icons, but core's SystemBars plugin loads too, resolves its default style from the system's night mode and posts it to the main thread after StatusBar has applied the config, so it always won: dark icons whenever the phone was in light mode. Both plugins also re-apply their own stale choice on every configuration change, so turning the system dark while the app ran kept the dark icons, and a light ZenNotes theme in a dark system got light icons on a light page. Neither plugin knows the theme. The shell now reads the theme where it lands, app-core's --z-bg on the root, so built-in themes, Auto, custom CSS themes and color tweaks all count, and hands it to a small Android-only plugin, SystemBarTheme, whenever it changes. The plugin paints the strips the app owns with the theme's background (the decor view, which shows behind the bars below WebView 140, and the window's bar colors before Android 15) and gives the icons whichever of white or black contrasts more with it. After a configuration change it re-applies once the other two plugins have had their turn. Dark navigation buttons need Android 8, so Android 7 keeps the launch theme's navigation bar. It does not touch the launch theme, the splash or the StatusBar config: until the WebView has measured the theme the app keeps its dark launch chrome, as before. Checked on an API 37 emulator (WebView 145): with the system in light mode the icons are white over the dark theme and turn dark the moment a light theme is picked; they keep following the theme through system dark-mode toggles, a resume and a rotation. On API 35 (WebView 124) the strip behind the bars now takes the light theme's background, with dark icons. Tests: system-bar-theme-color.test.ts checks every built-in theme's background against its mode and the contrast rule.
Ticking a task in the Calendar widget drew it ticked at once, but the day's header kept the snapshot's number (27 TUE ... 4) until the app ran and published a new snapshot. The header showed the snapshot's `total`, while the rows already followed the widget's tap log. The count now comes from the same log: the snapshot's total, less the day's listed tasks whose latest tap ticked them. An untick puts it back, and once the app has applied the tap its snapshot no longer lists the task and prunes the tap, so nothing is taken off twice. "+N more" still counts the rows a day leaves out, which no tap can reach. It does not touch the grid's corner mark, which counts open tasks written in the day's own note (a different number) and still waits for the app. Checked on an API 37 emulator with the app process killed: 3 went to 2 with the tick and back to 3 with the untick; after the app applied the tick and republished, the day read 2 with the task gone. Tests: CalendarAgendaTest (JVM) covers ticks written and queued, an untick, a pruned tap and the lower bound.
Opening a note from Home's Recent list raised the keyboard over half the screen with the caret on the first line, so a heading showed its raw `#`. The Tasks list and a widget's task link did the same when the app was already running. App-core hands the editor the keyboard focus whenever it opens a note from one of its lists or jumps to a task (#863, #415); on desktop that decides where typing goes, and core 2.57 brought it to the phones with no phone decision behind it. Inside a tap, Android shows the keyboard for that focus; the iPhone shows it for any focus. On the phone layout a note opened from a zennotes:// link (open, task, day, week) or from one of core's note lists (Home, Tasks, Quick Notes, Tags, Archive, Trash) now arms a short hold that refuses the editor focus core follows the open with, including its retries. Any touch releases it, so tapping into the text raises the keyboard as before, and whatever a tap elsewhere starts (a new note, the ensō dial's Quick, the Calendar's "Add a task") still focuses. A row's own controls (tick, pin, delete) do not arm it. Desktop-layout tablets keep core's behavior. read-open.ts and keyboard-hold.ts are the same files in both shells. It does not hide the `#`: core's live preview reveals the markers of the line holding the selection whether or not the editor has focus, and changing that is a core decision. Checked on an API 37 emulator: Recent rows, Tasks rows and a warm task link open with no keyboard and focus on the page; a tap into the text then raises it; Quick from the dial and the widget's "Add a task" still come up with the keyboard. Tests: keyboard-hold.test.ts covers the hold's timing.
…count that follows a tick, and no keyboard when opening a note to read it
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ZenNotes for Android 1.1.49 (versionCode 52), on core 2.78.0 (unchanged since 1.1.48). Fixes found while recording the 2.78.0 demos.
f10fbe9): the clock and icons drew near-black on a dark ZenNotes theme. Capacitor 8's SystemBars plugin chose the icon style from the system's light or dark mode, after the StatusBar config, and both re-applied that on every configuration change. The newSystemBarThemePlugin(withsrc/bridge/system-bar-theme.ts) paints the bars with the theme's--z-bgand picks white or black icons by contrast, following theme switches, system mode toggles, resume and rotation. Verified on API 37 (WebView 145) and API 35.d9af432): the day header showed the snapshot's total while the rows already followed the pending-tick log;CalendarAgenda.openCountsubtracts the day's pending ticks (6 new JVM tests).5993906): core's desktop focus hand-off (#863, #415) raised the keyboard for Home's Recent rows, the Tasks list and a warm widget task link. On the phone layout a read-open from azennotes://link or a core list now refuses that one focus; any touch releases it, so tapping into the text raises the keyboard as before.1a33f17): 1.1.49, versionCode 52.Validation: typecheck, 361 tests, build and sync; Gradle
testDebugUnitTest,lintDebug(0 errors) andassembleDebug. Each fix was reproduced and then verified on an emulator with before and after screenshots.