Problem
Both backends maintain separate clipboard read/write implementations:
- TUI (~100 lines): subprocess model via
find_clipboard_write_cmd() / find_clipboard_read_cmd() probing xclip/xsel/wl-copy/pbcopy. Sets engine.clipboard_read / engine.clipboard_write callbacks.
- GTK (~50 lines):
copypasta_ext library. 5 direct ctx.set_contents(text) calls scattered through hover copy, yank sync, terminal copy, etc. Does NOT use engine.clipboard_write.
A macOS backend would need a third implementation (NSPasteboard).
Proposed fix
GTK should use the same callback model as TUI — set engine.clipboard_read and engine.clipboard_write during init, then all clipboard operations go through the engine callbacks. The 5 direct ctx.set_contents() calls in GTK should route through engine.clipboard_write instead.
This also unblocks #381's remaining scope (clipboard read/write, not just paste detection).
Context
Identified in macOS backend readiness audit (Session 377). #381 shipped paste-key detection dedup but clipboard read/write remained per-backend.
Problem
Both backends maintain separate clipboard read/write implementations:
find_clipboard_write_cmd()/find_clipboard_read_cmd()probing xclip/xsel/wl-copy/pbcopy. Setsengine.clipboard_read/engine.clipboard_writecallbacks.copypasta_extlibrary. 5 directctx.set_contents(text)calls scattered through hover copy, yank sync, terminal copy, etc. Does NOT useengine.clipboard_write.A macOS backend would need a third implementation (NSPasteboard).
Proposed fix
GTK should use the same callback model as TUI — set
engine.clipboard_readandengine.clipboard_writeduring init, then all clipboard operations go through the engine callbacks. The 5 directctx.set_contents()calls in GTK should route throughengine.clipboard_writeinstead.This also unblocks #381's remaining scope (clipboard read/write, not just paste detection).
Context
Identified in macOS backend readiness audit (Session 377). #381 shipped paste-key detection dedup but clipboard read/write remained per-backend.