[PR #2150] [CLOSED] Windows: sync clipboard immediately on copy (both directions) + per-screen seqnum #1860

New issue

Closed

opened 2026-10-02 23:04:29 -06:00 by gitea-mirror · 0 comments

gitea-mirror commented

2026-10-02 23:04:29 -06:00

Owner

📋 Pull Request Information

Original PR: https://github.com/debauchee/barrier/pull/2150
Author: @ivanov84
Created: 9/1/2026
Status: ❌ Closed

Base: master ← Head: fix/windows-clipboard-sync

📝 Commits (6)

92627ab Windows: sync clipboard immediately on copy (both directions) + per-screen seqnum
85f02d4 Build: MSVC 2022 toolchain compatibility (C++17, std::filesystem, static CRT)
a0de883 Version 1.0.0 - first release of the barrier-win7-clipboard-auto-sync fork
a8b830a Add tools/barriertray: always-visible tray helper with log access
29b7238 barriertray: guard locale macros against command-line redefinition
ed0e186 README: describe the clipboard auto-sync fork

📊 Changes

16 files changed (+593 additions, -181 deletions)

View changed files

📝 .gitignore (+6 -0)
📝 CMakeLists.txt (+5 -4)
📝 README.md (+93 -148)
📝 cmake/Version.cmake (+4 -4)
📝 src/CMakeLists.txt (+1 -2)
📝 src/lib/barrier/App.cpp (+51 -0)
📝 src/lib/client/Client.cpp (+3 -5)
📝 src/lib/io/filesystem.cpp (+0 -3)
📝 src/lib/io/filesystem.h (+2 -2)
📝 src/lib/platform/MSWindowsScreen.cpp (+9 -4)
📝 src/lib/server/BaseClientProxy.cpp (+22 -1)
📝 src/lib/server/BaseClientProxy.h (+13 -0)
📝 src/lib/server/Server.cpp (+35 -8)
➕ tools/barriertray/barriertray.cpp (+348 -0)
➕ tools/barriertray/barriertray.rc (+1 -0)
➕ tools/barriertray/tray.ico (+0 -0)

📄 Description

Windows: sync clipboard immediately on copy (both directions) + per-screen seqnum

Problem

On Windows, copied text was only propagated to the other machine when the
mouse actually crossed into the other screen (grab), not on the copy itself.
On a headless server the user cannot see the remote mouse/second screen, so
they had to use external menu tricks to move the clipboard.

Additionally the server logs showed repeated
ignored screen "..." grab of clipboard 0/1 and missequenced clipboard
events: the server kept ONE shared per-clipboard sequence number while each
screen maintains its OWN seqnum. After the primary raised the shared seqnum,
the client's (effectively 0) grabs/updates were rejected as missequenced —
this is what caused intermittent dropped copies.

Fix

MSWindowsScreen::onClipboardChange — report every clipboard change
immediately (ungate the detection), not only on grab / mouse-leave.
Client::handleClipboardGrabbed — push the current clipboard to the
server immediately on grab (client → server).
Server::handleClipboardGrabbed — read the primary clipboard and
broadcast it to all clients on grab (server → client).
Server::onClipboardChanged — broadcast to all clients immediately.
Server + BaseClientProxy — track clipboard sequence numbers per
screen (each BaseClientProxy owns its own seqnum table, checked via
checkClipboardSeqNum), so a screen's independent seqnum is no longer
compared against another screen's value and rejected.
App::setupFileLogging (win32) — when no -l file is given, the node now
still keeps a complete rolling log at %APPDATA%\Barrier\logs\<exe>.log.
Previously the GUI only forwarded a limited stdout buffer, so "Show Log"
in the GUI was small and stale and there was nothing to copy for
diagnostics.

Testing

End-to-end on Windows: barriers + barrierc over loopback, 6+ repeated
copies from one machine to the other:

copies propagate immediately, both directions, no mouse movement needed;
0 missequenced rejections, 0 real drops (the only "ignored" lines are
the server correctly deduplicating the receiving client's echo of an
unchanged value);
processes stable throughout; full rolling log produced automatically.

This is a Windows-only behavioral change; Linux/macOS paths are untouched
(the always-on file log is guarded by SYSAPI_WIN32).

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/debauchee/barrier/pull/2150 **Author:** [@ivanov84](https://github.com/ivanov84) **Created:** 9/1/2026 **Status:** ❌ Closed **Base:** `master` ← **Head:** `fix/windows-clipboard-sync` --- ### 📝 Commits (6) - [`92627ab`](https://github.com/debauchee/barrier/commit/92627aba03b2788508c55bb13491e92b8bba87d3) Windows: sync clipboard immediately on copy (both directions) + per-screen seqnum - [`85f02d4`](https://github.com/debauchee/barrier/commit/85f02d4d910b714c90adc1474f5473e914cf719f) Build: MSVC 2022 toolchain compatibility (C++17, std::filesystem, static CRT) - [`a0de883`](https://github.com/debauchee/barrier/commit/a0de8832463b2b72db75994f1c2b3e73e676192e) Version 1.0.0 - first release of the barrier-win7-clipboard-auto-sync fork - [`a8b830a`](https://github.com/debauchee/barrier/commit/a8b830adb0a701de8c3ca8a3a1098024521c1711) Add tools/barriertray: always-visible tray helper with log access - [`29b7238`](https://github.com/debauchee/barrier/commit/29b7238b6f1b08970bea98afe59b876075b8ed48) barriertray: guard locale macros against command-line redefinition - [`ed0e186`](https://github.com/debauchee/barrier/commit/ed0e1861d36fb0be10486a9da9e0bf5cd2a9049a) README: describe the clipboard auto-sync fork ### 📊 Changes **16 files changed** (+593 additions, -181 deletions) <details> <summary>View changed files</summary> 📝 `.gitignore` (+6 -0) 📝 `CMakeLists.txt` (+5 -4) 📝 `README.md` (+93 -148) 📝 `cmake/Version.cmake` (+4 -4) 📝 `src/CMakeLists.txt` (+1 -2) 📝 `src/lib/barrier/App.cpp` (+51 -0) 📝 `src/lib/client/Client.cpp` (+3 -5) 📝 `src/lib/io/filesystem.cpp` (+0 -3) 📝 `src/lib/io/filesystem.h` (+2 -2) 📝 `src/lib/platform/MSWindowsScreen.cpp` (+9 -4) 📝 `src/lib/server/BaseClientProxy.cpp` (+22 -1) 📝 `src/lib/server/BaseClientProxy.h` (+13 -0) 📝 `src/lib/server/Server.cpp` (+35 -8) ➕ `tools/barriertray/barriertray.cpp` (+348 -0) ➕ `tools/barriertray/barriertray.rc` (+1 -0) ➕ `tools/barriertray/tray.ico` (+0 -0) </details> ### 📄 Description # Windows: sync clipboard immediately on copy (both directions) + per-screen seqnum ## Problem On Windows, copied text was only propagated to the other machine when the mouse actually crossed into the other screen (grab), not on the copy itself. On a headless server the user cannot see the remote mouse/second screen, so they had to use external menu tricks to move the clipboard. Additionally the server logs showed repeated `ignored screen "..." grab of clipboard 0/1` and missequenced clipboard events: the server kept ONE shared per-clipboard sequence number while each screen maintains its OWN seqnum. After the primary raised the shared seqnum, the client's (effectively 0) grabs/updates were rejected as missequenced — this is what caused intermittent dropped copies. ## Fix * `MSWindowsScreen::onClipboardChange` — report every clipboard change immediately (ungate the detection), not only on grab / mouse-leave. * `Client::handleClipboardGrabbed` — push the current clipboard to the server immediately on grab (client → server). * `Server::handleClipboardGrabbed` — read the primary clipboard and broadcast it to all clients on grab (server → client). * `Server::onClipboardChanged` — broadcast to all clients immediately. * `Server` + `BaseClientProxy` — track clipboard sequence numbers **per screen** (each `BaseClientProxy` owns its own seqnum table, checked via `checkClipboardSeqNum`), so a screen's independent seqnum is no longer compared against another screen's value and rejected. * `App::setupFileLogging` (win32) — when no `-l` file is given, the node now still keeps a complete rolling log at `%APPDATA%\Barrier\logs\<exe>.log`. Previously the GUI only forwarded a limited stdout buffer, so "Show Log" in the GUI was small and stale and there was nothing to copy for diagnostics. ## Testing End-to-end on Windows: `barriers` + `barrierc` over loopback, 6+ repeated copies from one machine to the other: * copies propagate immediately, both directions, no mouse movement needed; * 0 `missequenced` rejections, 0 real drops (the only "ignored" lines are the server correctly deduplicating the receiving client's echo of an unchanged value); * processes stable throughout; full rolling log produced automatically. This is a Windows-only behavioral change; Linux/macOS paths are untouched (the always-on file log is guarded by `SYSAPI_WIN32`). --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

gitea-mirror

2026-10-02 23:04:29 -06:00