Release 1.1.27: the shared 2.56.1 core, and a vault's own name on the phone - #85
Merged
Merged
Conversation
The shared core moves from 2.55.0 to 2.56.1 (`core-2.56.1-core.hc872c08b6872aec4`, built from ZenNotes/zennotes `f8b24c09` with a clean tree: the desktop 2.56.0 release plus the one core fix this shell needed). What the phone gets from 2.56.0: a vault can go by a name of its own while its folder keeps its name (ZenNotes/zennotes#692; Rename Vault… in the command palette, or the Vault name field under Settings, Vault), a Markdown table converts into a database linked from the note (#832; Convert Table to Database… in the palette with the cursor in a table), Settings search reaches every setting and knows where new tasks go, a task added or moved from the calendar panel joins the note's Tasks section (#851), a task's code block stays under its text in Preview (#849), undo after the open note changed on disk (a sync, for one) starts a clean history instead of saving a mixed text (#852), and the in-app Help reads as one page. The template shortcuts (#847) are keyboard-only and do nothing here. Two things the shell had to do for #692. The core takes a vault's folder name from its root, and this shell's root is a label ("On this device › ZenNotes › docs"), so without help the first settings save renamed the vault to the whole label; 2.56.1 lets a host name the folder itself, and `currentVaultInfo` now hands over `folderName`. And the core only re-derives the name after a settings save, so `describeCurrentVault` resolves the display name from vault.json whenever a bridge method returns the open vault (desktop does the same in main), and the vault switcher reads each folder's vault.json to list vaults by the name they go by. A test pins that a name written by the desktop survives a settings save from this device. Adopted with `npm run core:adopt -- core-2.56.1-core.hc872c08b6872aec4 --source f8b24c09af1828b5242d572c7636df83236e2586`: every archive's SHA-256 and SHA-512 checked against its provenance, all three recording that source commit; the boundary check passed without an override.
…ach vault's own name Found while driving the same change on the iPhone simulator. The Vaults sheet lists folders, and its rename and delete act on the folder, but it marked the open vault by comparing an entry's folder name with the name the shell snapshot shows. Once a vault carries a display name (ZenNotes #692, core 2.56.x) those are different strings, so a renamed vault lost its check mark, its row became tappable, and the manage view offered Delete and Rename for the vault that was open. The sheet now asks the bridge for the open vault's folder name (`currentVaultFolderName`, the MobileVault it holds) and compares that, the external-root clause unchanged; the snapshot's name is only what the open vault's row shows. The other rows show the name each vault goes by, read from its own vault.json (one small read per local or cloud folder, no download wait for an evicted cloud file, which keeps its folder name), and the manage view names the folder beside a display name that differs, so a rename or delete is understood to act on the folder. `MobileVaultEntry` gains `displayName`; `name` stays the folder, which every management call keys on.
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
1 participant
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.
Release 1.1.27 (versionCode 30): the shared ZenNotes core moves from 2.55.0 to 2.56.1 (
core-2.56.1-core.hc872c08b6872aec4, built from ZenNotes/zennotesf8b24c09with a clean tree: the desktop 2.56.0 release plus the one core fix this shell needed), adopted withnpm run core:adoptand verified against its provenance.On the phone: a vault can go by a name of its own while its folder keeps its name (ZenNotes/zennotes#692; Rename Vault… in the command palette, or the Vault name field under Settings → Vault). The core took the folder name from the vault's root, and this shell's root is a label ("On this device › ZenNotes › docs"), so without help the first settings save renamed the vault to the whole label; core 2.56.1 lets a host name the folder itself,
currentVaultInfohands overfolderName,describeCurrentVaultresolves the display name from vault.json whenever a bridge method returns the open vault, and the vault switcher lists each vault by the name it goes by. Also from the core: a Markdown table converts into a database linked from the note (#832, Convert Table to Database… in the palette), Settings search reaches every setting and knows where new tasks go, a task added or moved from the calendar panel joins the note's Tasks section (#851), a task's code block stays under its text in Preview (#849), undo after the open note changed on disk starts a clean history instead of saving a mixed text (#852), and the in-app Help reads as one page. The template shortcuts (#847) are keyboard-only and do nothing here.Two commits: the adoption (with the shell changes for #692 and a test that a desktop-written name survives a settings save from this device) and the version bump. No native code changes. The signed bundle is built from the bump commit for Play; the Play-signed universal APK goes on the GitHub release after Play processes it.