fix: use GET_PRIVATE_LINK socket command for Wayland clipboard support#12
fix: use GET_PRIVATE_LINK socket command for Wayland clipboard support#12DeepDiver1975 wants to merge 1 commit into
Conversation
On Wayland, the ownCloud daemon has no compositor surface and cannot write to the clipboard via Qt. Intercept COPY_PRIVATE_LINK on Wayland, request the URL back from the client via the new GET_PRIVATE_LINK command, and write the clipboard via GTK from within Nautilus (which owns a live Wayland surface). Falls back to the original COPY_PRIVATE_LINK path on non-Wayland sessions and when the client does not support GET_PRIVATE_LINK. Closes: #11 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Thomas Müller <1005065+DeepDiver1975@users.noreply.github.com>
907ce34 to
db878eb
Compare
dj4oC
left a comment
There was a problem hiding this comment.
Companion to the Dolphin extension's Wayland clipboard fix: on Wayland, context_menu_action intercepts COPY_PRIVATE_LINK, sends GET_PRIVATE_LINK:<file>, polls for up to 0.5s for a PRIVATE_LINK: reply, and writes it to the clipboard via GTK3/GTK4 (versioned correctly), falling back to the original socket command on timeout or GTK failure.
Findings
Memory safety: Python — no manual memory management; the GTK clipboard write is wrapped in a broad try/except, which is appropriate here.
Stability/UX concern: _request_private_link polls synchronously inside context_menu_action, briefly blocking the Nautilus extension's calling thread for up to 0.5s. Same category of concern as the Dolphin companion PR, and the timeout (0.5s here vs. 1s in the Dolphin PR) is inconsistent between the two extensions for what should be the same UX.
Cross-repo dependency risk (blocking): Depends on GET_PRIVATE_LINK, added in owncloud/client PR #12535, which this same automated review flagged with a stability: Block finding (use-after-free risk if the socket disconnects before the async reply arrives). Recommend holding this PR until that's fixed upstream.
Platform API: GTK3/GTK4 dual-path clipboard handling is correctly version-gated.
REUSE: Additive changes to an existing licensed file; no new files.
Verdict
Changes requested (pending the upstream client-side fix)
🤖 Automated review by Claude Code (memory-safety · platform-API · REUSE)
Generated by Claude Code
Problem
On native Wayland sessions the ownCloud daemon has no compositor surface, so
QClipboard::setText()is silently dropped by the compositor. Copy private link toclipboard never works on Wayland.
Solution
When the session is Wayland, the extension sends
GET_PRIVATE_LINK:<file>to the client(a new socket command added in owncloud/client) and waits for
PRIVATE_LINK:<url>. Itthen writes to the clipboard via GTK from within the Nautilus process, which does own an
active Wayland surface.
Falls back to the original
COPY_PRIVATE_LINKpath on X11 sessions and when the clientversion predates the new command (timeout → fall-through).
What changed vs PR #11
Requires: owncloud/client PR for
GET_PRIVATE_LINKcommand.Testing
"Copy private link to clipboard" → clipboard contains the URL ✓