fix(share): send shared plain text to the laptop clipboard - #11
Open
X-Ryl669 wants to merge 1 commit into
Open
Conversation
A `text/plain` share only did something when the text contained a URL, which took the browsing-handoff path. Anything else fell through to the file loop, where a text share has no EXTRA_STREAM — so it iterated zero URIs and ended on the toast "Couldn't read the shared file(s)". Nothing was ever transmitted, and the laptop never logged a receive. The manifest advertises `text/plain` for this activity, so Vortex offers itself as a target for text and has to honour it. Route plain text to `VortexService.clipboardBus`, the bus the Quick Settings tile already uses, so it inherits the enable check, the character cap, the CLIPBOARD_TEXT chunking and the per-peer send. Guarded on an empty URI list so a caption shared ALONGSIDE an attachment doesn't hijack the file. The order is now: URL → handoff, attachment → file, plain text → clipboard. Laptop side: the receive path threw away the result of `set_system_text` with `let _ =`, which made a refused clipboard write indistinguishable from text that never arrived — the exact ambiguity that made this bug hard to place. Log the failure (the image path always did) and only claim "synced from phone" when the write actually succeeded; keep the text in history either way so it stays reachable from the Super+V popup. Verified end-to-end on a PJZ110 (Android 16) over wireless-debugging adb: the phone logs "share: forwarded 28 chars to the laptop clipboard" and the text lands in the laptop's Wayland clipboard. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
2 participants
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.
This fixes a bug while sharing textual content without an URL from the phone. It failed with a "Couldn't read the shared file" message. This isn't specific to KDE but generic to all platform.
Here's Claude take at it:
A
text/plainshare only did something when the text contained a URL, which took the browsing-handoff path. Anything else fell through to the file loop, where a text share has no EXTRA_STREAM — so it iterated zero URIs and ended on the toast "Couldn't read the shared file(s)". Nothing was ever transmitted, and the laptop never logged a receive. The manifest advertisestext/plainfor this activity, so Vortex offers itself as a target for text and has to honour it.Route plain text to
VortexService.clipboardBus, the bus the Quick Settings tile already uses, so it inherits the enable check, the character cap, the CLIPBOARD_TEXT chunking and the per-peer send. Guarded on an empty URI list so a caption shared ALONGSIDE an attachment doesn't hijack the file. The order is now: URL → handoff, attachment → file, plain text → clipboard.Laptop side: the receive path threw away the result of
set_system_textwithlet _ =, which made a refused clipboard write indistinguishable from text that never arrived — the exact ambiguity that made this bug hard to place. Log the failure (the image path always did) and only claim "synced from phone" when the write actually succeeded; keep the text in history either way so it stays reachable from the Super+V popup.Verified end-to-end on a PJZ110 (Android 16) over wireless-debugging adb: the phone logs "share: forwarded 28 chars to the laptop clipboard" and the text lands in the laptop's Wayland clipboard.