-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] clipboard clears when source window is closed #5480
Comments
This is by design. A clipboard manager is required for this to work. |
Unfortunately clipboard managers break some applications under the current paradigm: https://github.com/yory8/clipman/issues/43#issuecomment-687562862 Is it possible support for clipboard persistence in sway could be reconsidered, seeing as it is currently impossible to get the same non-intrusive clipboard manager behavior as in X11? |
X11 clipboard managers like KDE's do this:
Wayland is no different from X11. |
But under wayland, what mechanism can be used to detect when the selection is unset? It seems that's the piece that's either missing or currently unknown to the clipman developers. |
When the selection is reset, a NULL selection event is sent. |
Oh, that's perfect, thanks! Now I think I see the relevant code in |
@emersion you've previously (one, two) argued that it's not worth supporting that, and instead clipboard managers should just stick to taking over the selection immediately. If you've changed your mind, or if I misunderstood you in the first place, I'd be happy to discuss a protocol extension that would enable clipboard managers to implement the above 😀
As I pointed out elsewhere, a nil selection even is not enough to distinguish an explicitly unset selection from "lost" selection due to client exiting, nor is there any way for the clipboard manager to replace the selection atomically on client exit. |
There's no need for any new protocol extension/update.
What I described is the KDE clipboard manager behaviour. You're free to do something else. |
Indeed, you can implement something else. The problem is, you cannot do that same thing, if you want to — developers of external clipboard managers for Sway cannot implement the same behavior as the KDE behavior you described. I can understand if your position is one shouldn't implement that, so adding APIs for it is not worth it. But that's not the same thing as saying that all the necessary APIs are there, and it's only the lack of will that's stopping clipman (or other clipboard managers) developers from implementing it.
The please describe how one would overcome the two limitations I've mentioned above 🙂 |
What limitations? We offer the same features and limitations as X11. At least the KDE clipboad manager folks don't need anything else. |
There are two limitations; let me describe them again:
As the KDE clipboard persistence implementation (in Klipper) apparently also uses wlr-data-control, they also suffer from the same limitations:
Correction: they can of course implement the same behavior since KDE is using wlr-data-control too; but they cannot implement it right (neither can KDE).
Heh, X11 is not a particularly great gold standard to measure yourself against. I know of Mutter's built-in clipboard manager, which (by virtue of being implemented inside the compositor) doesn't suffer from these problems. It correctly distinguishes between explicit clear vs destroyed selection, and (I believe) doesn't race with clients. If we want to match this with external clipboard managers, we need those protocol improvements I (and now KDE folks) keep mentioning. |
sway 1.4
(no xwayland)
Description:
With any 2 windows open copy-paste between windows works until both windows stay open (e.g. terminal and browser)
As soon as window from where the copy operation was performed is closed clipboard contents are erased and it is not possible to paste anymore.
Steps to Reproduce
The text was updated successfully, but these errors were encountered: