mirror of
https://github.com/storytold/vectorcraft.git
synced 2026-11-13 21:17:48 +00:00
dotCooCoo
0fd757c6b8
On Linux the Paste menu's background check holds its own clipboard handle. When the app quit while that check's X11 text read was still unanswered, quitting stopped waiting for the check's thread after 5 s, but the handle's read worker holds arboard's handle until 25 s after the read was sent. The app's own handle was then dropped first, so it was not the last one alive to hand what was copied to a clipboard manager. - CLIPBOARD_PROBE_STOP_WAIT (27 s, exported from vectorcraft-ui-egui) replaces the 5 s bound: the 25 s X11 read limit plus LOAD_WAIT, the 2 s limit on waiting for a reader to stop. Quitting still ends after it when a host's handle never lets go. - On Linux and the BSDs, on_exit hides the main window before eframe drops the app, so the window closes at once while the process waits for the clipboard handles. The window is hidden, not closed, and the connection the clipboards use stays open. winit hides X11 windows, XWayland ones included; it cannot hide a native Wayland window, which stays on screen until the wait ends. macOS and Windows are unchanged. - Probe's Drop waits through an injectable function, so a test drives the wait with a controllable clock while the probe's handle is still being dropped and checks that it is dropped before the app's. - A Linux test in the app checks the bound against X11_READ_LIMIT and LOAD_WAIT, so raising either fails it. - Comments and docs/development.md describe the wait.