Cut the 0.5.0 release (light/dark theme support): daemon
Cargo.toml/Cargo.lock to 0.5.0 (no code change, kept in lockstep with the
tag), extension metadata.json version to 5, and promote the CHANGELOG
[Unreleased] entry to [0.5.0] - 2026-05-26.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Cut the 0.4.0 release: daemon Cargo.toml/Cargo.lock to 0.4.0, extension
metadata.json version to 4, and promote the CHANGELOG [Unreleased] entry
to [0.4.0] - 2026-05-26.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The monitor.rs comments claimed Mutter implements ext-data-control-v1 on
GNOME 47+, contradicting ARCHITECTURE.md. Mutter exposes neither
ext-data-control-v1 nor zwlr-data-control-v1, so the monitor never binds
on GNOME and ingest comes from the extension via Meta.Selection +
SubmitItem; the monitor only runs on wlroots. Correct the comments
(module doc, Ext probe, bail! message) and the main.rs spawn comment.
Also reconcile ARCHITECTURE.md with the code: supervisor backoff
(1/2/4/8/16 s, 5 s reset, log-only give-up), SIGTERM at 1.5 s, prune as a
separate post-insert call, multi-thread tokio default, the 200 px
load-more threshold, and the SQL-side preview truncation.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
GetHistory and SearchHistory selected the full content_text column for
every row, so a page of large text items serialized up to megabytes of
JSON over D-Bus and parsed it on the GJS main loop, only to render a
~140-char snippet. The client-side cut never bounded the wire cost.
Truncate to PREVIEW_CHARS (200) with substr() in SQL on both list paths.
Full content is still served on demand by GetItemContent for paste-back.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The column is defined in the initial CREATE TABLE statement, so the
ALTER TABLE migration was redundant from day one -- it always failed
silently via .ok(). No existing user databases lack this column.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The D-Bus interface previously returned content as a base64-encoded
string (type 's'), requiring the daemon to encode and GJS to decode
on every paste. D-Bus natively supports byte arrays (type 'ay'),
eliminating both encode and decode steps entirely.
Changes:
- dbus_service.rs: return (String, Vec<u8>); drop base64 calls
- dbus.js: content_b64 arg changed from type 's' to type 'ay'
- panel.js: remove GLib.base64_decode(); pass ay bytes directly
- Cargo.toml/Cargo.lock: remove base64 dependency (no longer used)
For a 1 MB text paste this avoids allocating a 1.33 MB intermediate
string and decoding it on the compositor main thread.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The daemon stored the focused app ID but never read it. App exclusion
runs entirely in the extension before SubmitItem is called, so the
D-Bus round-trip on every window focus change was pure overhead.
Removed from: extension.js call site, dbus.js XML interface,
dbus_service.rs method + struct field, main.rs Arc allocation.
Focus tracking in _connectFocusTracking is kept since _currentFocusedApp
is still used for the JS-side exclusion check.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The previous fallback to PathBuf::from(".") silently placed the
database in whatever the current working directory was, making it
impossible to find later. Since the daemon cannot function without a
persistent database, failing fast with an actionable message is the
correct behavior.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
write_to_clipboard took ownership of WriteRequest but immediately
cloned both fields into locals, then cloned bytes again for the text
path -- three heap allocations on a potentially large byte buffer.
Destructure the owned request directly and move the fields. The text
path still needs one clone (bytes goes into two MimeSources), but the
extra upfront clones are gone.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
get_raw_item is used by GetItemContent (paste-back) and SetClipboard.
Neither caller needs the thumbnail -- they only need the original
payload. Excluding thumbnail_blob from the SELECT avoids loading up to
~40 KB of PNG data per paste operation.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Previously prune() ran two identical NOT IN (SELECT ... ORDER BY
created_at DESC LIMIT n) subqueries: one to collect IDs for signals,
one to delete. SQLite executed the ORDER BY pass twice.
Now we collect the IDs first with a single subquery, then delete by
those exact IDs using params_from_iter. The ORDER BY scan runs once
regardless of how many items are pruned.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
make_thumbnail was computing a base64 string of the thumbnail on every
image clipboard capture. The caller only ever used the raw bytes and
immediately discarded the String. Remove the base64 encode, simplify
the return type to Result<Vec<u8>>, and drop the now-unused
'use base64::Engine' import from main.rs.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
