Repository navigation
Conversation
The updater broadcasts a new state about once a second during a download. Sidebar and SettingsModal each subscribed at the top of the whole component, so every tick re-rendered the entire sidebar (77 components) and, with Settings open, the entire dialog, to repaint one percentage. The subscription now lives in the leaves that show it: SidebarSettingsAction for the footer badge and AppUpdatesCard for Settings > About. Same markup, badges, titles and buttons; the Settings row keeps its sidebar index across lone re-renders. Per tick: 77 -> 8 components with the editor open, 83 -> 6 with Settings open. This does not claim to fix #868 (typing lost during a download on Niri/Wayland), which does not reproduce on macOS and is waiting on the reporter; it removes churn from the path while that is narrowed down.
Every Linux package since 2.52.0 installed resources/terminal as a root-owned 0700 folder: the tarball (and the AUR package, which copies it with cp -a), the .deb and the .pacman. The terminal stager builds that folder with mkdtemp, which always creates 0700, then renames it into place, and the packagers keep the mode. The files inside were readable, but no user could enter the folder, so the app never read the manifest, never activated the pinned Go zn, and kept everyone on the legacy Node CLI. Settings > CLI blamed an invalid manifest, because the runtime treated every read failure other than a missing file as a bad manifest. The stager now sets the folder and zn to 0755 and LICENSE and manifest.json to 0644 with chmod, so a builder's umask cannot narrow them. The runtime reports EACCES/EPERM on the bundle as a permission problem, naming the folder and the fix, and keeps "invalid" for a manifest that does not parse. Checked by building the linux-x64 tarball, .deb and .pacman on macOS before and after: resources/terminal goes from drwx------ to drwxr-xr-x root:root in all three. The macOS app carried the same 0700 folder; it worked for the account that installed it, not for other accounts on the same Mac. Upgrading fixes existing installs; until then the workaround is sudo chmod 755 on the installed resources/terminal.
3dec2a6 made new packages ship resources/terminal readable, but that only helped fresh installs. dpkg and pacman keep the permissions of a folder that already exists when they upgrade a package (pacman says "directory permissions differ ... filesystem: 700 package: 755" and leaves it), so every install of 2.52.0 to 2.57.0, the people #869 is about, would have kept the locked folder and the legacy CLI after upgrading. 3dec2a6's message said upgrading fixes existing installs; it did not, and this change is what does. The bundle now ships as resources/zn-cli. A folder the old package never had is created with the mode in the package, and the old locked folder goes away with the old package's files. The dev path is unchanged. Checked on Ubuntu 26.04 and Arch in Docker, installing the released 2.57.0 as root and then this build over it: with dpkg, with the .pacman, and with the AUR package built by makepkg (2.57.0-1, then 2.57.0-2 from this tarball), resources/terminal is gone and resources/zn-cli is drwxr-xr-x. Run as a normal user with the same user data before and after, Settings > CLI goes from "The bundled terminal manifest is invalid." to the Go CLI, and zn --version prints zn v0.4.1. An unsigned packaged macOS build finds the bundle at the new path and activates the same version.
The .pacman package shipped electron-builder's default pacman dependency list, which names http-parser. Arch dropped http-parser, so pacman -U on an up-to-date Arch stops with 'cannot resolve "http-parser"' and installs nothing; only -dd got past it. Most of that list was stale for an Electron app anyway: ffmpeg is bundled as libffmpeg.so, and c-ares, libevent, libvpx, libxslt, minizip, re2 and snappy are built in, so the binary links none of them. It links neither libXss nor libappindicator either, and ZenNotes has no tray icon. The list now comes from what the app actually loads. On a bare Arch install of the package, readelf and ldd put every library ZenNotes links under gtk3, nss and alsa-lib (with what they pull in), plus mesa for libgbm, which Electron links directly. libnotify (desktop notifications) and libsecret (the keyring behind saved cloud credentials) are loaded at runtime, so no linker check sees them. xdg-utils opens links and files in other apps, and desktop-file-utils registers the zennotes:// handler from the package's .desktop entry, as in the AUR package. Checked in a fresh archlinux container with nothing skipped: the 2.57.0 .pacman still fails on http-parser; this one installs, no library is missing, zennotes:// lands in mimeinfo.cache, and launched as a normal user through /usr/bin/zennotes it opens with the Go CLI active.
The .deb shipped electron-builder's default deb dependency list, which does not name libasound2 even though the app links libasound.so.2 directly, and does not name libgbm1 either. Desktop installs have both, so it went unnoticed, but on a minimal system apt installed ZenNotes cleanly and the app then refused to start: "error while loading shared libraries: libasound.so.2" (exit 127 on a clean Ubuntu 26.04). Ubuntu 22.04 also left libgbm.so.1 missing. The list keeps electron-builder's defaults and adds libgbm1 and "libasound2t64 | libasound2". The alternative covers the t64 rename: libasound2 is the real package on Ubuntu 22.04 and Debian 12, while on Ubuntu 24.04+ and Debian 13 the real one is libasound2t64 and libasound2 is only a virtual name that the OSS shim liboss4-salsa-asound2 also provides, so the real package is named first. Checked with apt on clean Ubuntu 22.04, 24.04 and 26.04 and Debian 12 and 13: the current .deb leaves libasound.so.2 unresolved on all five; this one resolves every library the app links, libasound.so.2 comes from the real ALSA package on each, and the app launches as a normal user on 22.04 and 26.04. The .rpm needs no change: a clean Fedora 44 installs the 2.57.0 .rpm with nothing missing.
One Quick Connect saved two remote workspaces for the same server: the one you connected to and a "ZenNotes Server" with no vault and no token, and the vault switcher listed both. Quick Connect persists the live connection (remoteWorkspace) a moment before it saves the profile, and the config loader made up a "ZenNotes Server" profile for any remoteWorkspace without a profile at the same URL, with a new random id on every load. The profile save then wrote that made-up entry to disk. The loader now makes one up only for a config from before saved profiles existed (no remoteWorkspaceProfiles key at all), which is what that migration was for; in a current config remoteWorkspace is just the live connection. An extra entry that is already saved stays until the user removes it, since it looks exactly like a real one. Connect on a saved workspace with no token, when the server needs one, now names the workspace and points at Edit, instead of saying to check a token that was never sent. Reproduced with a scratch server and the built app over CDP: one Quick Connect saved both profiles, and Connect on the extra one gave the misleading error. With this change the same run saves one profile with its token, and a tokenless profile gets the new message. Three config tests cover the pre-profile migration and the Quick Connect write order.
Connected to a remote vault, Settings > Vault > Location put its four buttons (Change Remote Vault, Return to Local Vault, Open Local Vault, Quick Connect) on one line beside the label, and the line never wrapped. The buttons could not shrink, so only the label gave way: at about 1000 px of window width and below it collapsed to nothing, the first button covered "Remote workspace", Quick Connect was cut off at the card's edge, and the vault path and server address vanished. The row now wraps. The label keeps a minimum width, and the buttons are one group that moves under it when the row is too narrow and wraps within itself when it is narrower still, with the 8 px spacing the other Settings button groups use. Measured over CDP at 1280, 1100, 1000, 900, 800 and 700 px, connected to a scratch server: before, the label box was 0 px wide at 1000 px and below with a button on top of it and one to three buttons clipped; after, the label stays on one line and no button overlaps it or runs past the card at any width, for both the remote row and the local one.
This branch was successfully deployed
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.
ZenNotes 2.58.0, cut from branch
v2.58.0.mainfast-forwards to this branch once the checks pass; the tagv2.58.0goes on the release commit.Fixes
znswitches on for Linux package installs (the AUR package,.deb,.pacman), including upgrades from 2.52.0 to 2.57.0. The bundled CLI folder shipped root-owned and0700, so the app could not read it and keptznon the legacy CLI. It now ships world-readable under a new name,resources/zn-cli, because dpkg and pacman keep an existing folder's mode on upgrade. Settings → CLI reports an unreadable bundle as a permission problem ([Bug] Linux tarball ships resources/terminal as 700, so the Go CLI never activates #869, from @diazkev314)..pacmaninstalls on current Arch: its dependency list no longer nameshttp-parser, which Arch dropped, and now lists what the app loads..debstarts on minimal Ubuntu and Debian: it pulls in the audio library (libasound2t64 | libasound2) andlibgbm1, which the app links.Tooling
aur-bump.shrefuses a Linux tarball whose bundled CLI folder is not world-readable or still uses the old name.Docs
Release notes and the verification log live in
docs/releases/v2.58.0/(local).