Class ClipboardHelper
- Namespace
- SharpConsoleUI.Helpers
- Assembly
- SharpConsoleUI.dll
Cross-platform clipboard helper for console applications. On Linux tries wl-clipboard, xclip, xsel. Falls back to an in-process buffer when no external tool is available. Operations are best-effort and will not throw on failure.
public static class ClipboardHelper
- Inheritance
-
ClipboardHelper
- Inherited Members
Properties
Backend
The clipboard backend currently in use. Triggers detection on first access.
public static ClipboardBackend Backend { get; }
Property Value
MaxOsc52Bytes
Maximum base64 payload size for OSC 52; larger copies skip OSC 52.
public static int MaxOsc52Bytes { get; set; }
Property Value
Osc52Mode
Controls OSC 52 emission on copy. Default Auto.
public static Osc52Mode Osc52Mode { get; set; }
Property Value
Methods
GetText()
Returns the current text content of the system clipboard, or empty string on failure.
public static string GetText()
Returns
GetTextWithTimeout(int)
Returns the clipboard text without ever blocking the caller for more than
timeoutMs milliseconds. The Windows path is the in-process Win32 read (instant),
but the Unix backends spawn a child process (xclip -o / wl-paste / pbpaste) that
can stall — running that on the UI thread is the same watchdog hazard as the Windows copy was
(issue #42). This runs the read on a background thread and, if it does not complete in time, returns
the in-process buffer so a paste can never hang the render loop. Use this from UI-thread paste paths;
GetText() remains the (possibly blocking) full-fidelity read for non-UI callers/tests.
public static string GetTextWithTimeout(int timeoutMs = 200)
Parameters
timeoutMsint
Returns
SetText(string)
Copies the specified text to the system clipboard.
public static void SetText(string text)
Parameters
textstring
Remarks
The external-tool backends (clip.exe, pbcopy, xclip, xsel, wl-copy) spawn a process and
wait on it. That blocking I/O is dispatched to a background thread so a copy never stalls
the UI/render thread — on Windows, spawning clip.exe per copy was slow enough to
trip the main-loop "unresponsive" watchdog (issue #42). OSC 52 emission and the in-process
fallback are cheap and stay synchronous, so callers and tests observe them immediately.