-
Notifications
You must be signed in to change notification settings - Fork 994
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
Weird cllipboard behavior #1889
Comments
This is as expected. I suspect you can reproduce a behavior you're not going to like without using two different viewers/remotes:
When selecting text, that text is actually copied to the selection clipboard, which is commonly pasted using middle-mouse. Linux has two different clipboards, and VNC combines them into one. |
@samhed, I'd ask you to reopen this issue. It is actually NOT as you'we written! If I do what you suggest, 'BBB' would be pasted in stage 4 (that's what I am complaining about - please read my issue above carefully again... ;-)). And no, I wouldn't nor expect that (as 'BBB' has not been copied in stage 3, just selected and written over; 'AAA' should remain in clipboard at this stage!) nor I like it. Why would anyone expect that at all?! I find it very annoying in fact. As I copy something into the clipboard and would like to paste it to 4 remote machines (one after another), but the clipboard is actually overwritten again and again with the content on remote machines just being selected (to paste over) and NOT copied! It is a weird and in some cases very annoying behavior in contrary as anyone would expect (no matter how many clipboards a system has - if something is just selected and not copied, it should not spoil any of the clipboard contents, or?). |
Depending on the used Desktop-software and its setup, selecting text will cause copying. This is how Linux would normally work, intentionally. (it may be possible to turn that behavior off, but why would one want to do so?? ;-) Am I misunderstanding the issue here? |
@L-U-T-i I did not misread your text. And I re-tested the steps I outlined, things do behave like I wrote. |
May I ask you to explain me this. If I copy some text (say "Text No.1") in one Pluma window to clipboard (select it, right click on it and click to "Copy"), and after that I just select some other text (say "Text No.2") in another Pluma window (or Firefox or whatever you want...), but I don't copy that one to a clipboard, according to you, "Text No.2" will be pasted to some other Pluma window (or, wherever else you want...)?! I've never ever heard something like that, nor experienced it (in my about 35+ years of experience with Winblow$ and linux)! How would it be possible to paste some text over another text if things would work as you claim?! I use such feature many times - to replace just a substring, for instance. And, it always work as expected - to paste the previously selected and copied text over. According to you, nothing would be replaced (as the same text - just selected to be replaced - would just be pasted over itself... |
it seems you did, unfortunately. Or, misunderstand it. The steps you've outlined are exactly the same thing I would expect, but not exactly what I am complaining about! What you write happens with just 1 single remote machine. And, it is as expected (it has been an issue some years ago as well, but has been resolved then). But, if you try to paste the same text ('AAA', copied from a local machine) to 2 different remote machines (where the first one has some text already selected, say "BBB"), "AAA" overwrites "BBB" (as you say, and as expected), but after that "BBB" is pasted on a second machine (despite the fact that "BBB" has never been copied to a clipboard, just selected to be pasted over on the 1st remote machine...). This is my issue (since the beginning). I hope you agree that this is not an expected behavior. |
Hm, my experience is different. Ever since the Unix days, I would have expected the action of selecting text to also place that in the clipboard, ready to be pasted with M2/middle-mouse. If that does not happen, my take on it would be that it is a software-specific behavior, or the thing is broken. (yes, I'm fully ignorant regarding Pluma) The last text selected is what is in the clipboard. (which seems contrary to your comment: " I just select some other text (say "Text No.2") in another Pluma window (or Firefox or whatever you want...), but I don't copy that one to a clipboard, according to you, "Text No.2" will be pasted to some other Pluma window (or, wherever else you want...)?!". Loving that behavior of easy and fast text-replication, I used to use a utility called TX-Mouse successfully in WinXP, almost as successfully in Win7 but never really invested the time to see if I can also use it in Win10/Win11, although I should;-). |
What you are describing is the difference between the Clipboard and the
Primary selection. The clipboard implements the explicit cut-copy-paste
mechanism, whereas the Primary selection is where text (and only text I
believe) that was previously highlighted is stored and can be pasted via
the middle mouse button. So that is normal X11 behavior.
Sent from Gmail Mobile
…On Wed, Jan 8, 2025 at 11:53 PM MBD62 ***@***.***> wrote:
May I ask you to explain me this. If I copy some text (say "Text No.1") in
one Pluma window to clipboard (select it, right click on it and click to
"Copy"), and after that I just select some other text (say "Text No.2") in
another Pluma window (or Firefox or whatever you want...), but I don't copy
that one to a clipboard, according to you, "Text No.2" will be pasted to
some other Pluma window (or, wherever else you want...)?! I've never ever
heard something like that, nor experienced it (in my about 35+ years of
experience with Winblow$ and linux)!
Hm, my experience is different. Ever since the Unix days, I would have
expected the action of selecting text to also place that in the clipboard,
ready to be pasted with M2/middle-mouse. If that does *not* happen, my
take on it would be that it is a software-specific behavior, or the thing
is broken. (yes, I'm fully ignorant regarding Pluma) The last text selected
is what is in the clipboard. (which seems contrary to your comment: " I
just select some other text (say "Text No.2") in another Pluma window (or
Firefox or whatever you want...), *but I don't copy that one to a
clipboard*, according to you, "Text No.2" will be pasted to some other
Pluma window (or, wherever else you want...)?!".
My expectation here would be that "Text No.2" is in the clipboard, if it
was last selected on that computer. In other words, I don't know how to
*not* copy selected text in Unix/Linux)
Loving that behavior of easy and fast text-replication, I used to use a
utility called TX-Mouse successfully in WinXP, almost as successfully in
Win7 but never really invested the time to see if I can also use it in
Win10/Win11, although I should;-).
—
Reply to this email directly, view it on GitHub
<#1889 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB45M3IE52V64I27WP642AL2JX6EJAVCNFSM6AAAAABUDR6XZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZZGE3TQMJXGQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
I am not talking about middle mouse button at all. If you are not familiar with Pluma, take Gnome Text editor with 3 open files / windows or 3 Terminal windows, write "Text 1" and "Text 2" in two of them. Select "Text 1", right click on it and select "Copy". Select "Text 2" in 2nd window after, RIGHT click on it and select "Paste". According to you, "Text 2" should be pasted over itself (as the last text selected and somehow "automatically" copied), but I've never ever experienced that (in any linux / windows). "Text 1" is pasted over, and if I go to the 3rd window and right click & paste there, "Text 1" is pasted as well. As I would expect it and as it sounds the only reasonable consequence of the actions taken. Not speaking about VNC at all, only local desktop with 3 windows (can also be mixed - text editor and terminal window or Firefox or Gimp or whatever else you like). And no, I couldn't find (haven't even looked for it, to be honest) any option to tweak any clipboard behavior / actions, not in the application level nor in the system level. I've always used the default (and always got "right click" - or through a menu - pasted the last explicitely copied text). Since Fedora 6 (or whatever it has been at that time) and Centos 3 or 4, as well as in Window since 3.11 or Workgroups or whatever has been first... Thanks God @bphinz explained to both of us what is one and what is the other talking about. But I take the Clipboard actions as normal, and the Primary selection (I haven't ever used it and never even mised it by now) as a specific use (I believe left and right click are more common use than the middle one...). And, I've never ever talked about any middle mouse click or something like that (so, no Primary selection, just a pure Clipboard actions). |
Describe the bug
If the text is copied from a local machine and pasted to the first remote machine overwriting some other text, the clipboard content seem to change and - instead of locally copied text - the text which has just been overwritten on the first remote machine is pasted into the second remote machine after.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I would expect the same text just copied from from the local machine will be pasted on the 1st and on the 2nd remote desktop, as nothing has to be copied in between (paste over some other text should not copy the existing text being overwritten into the clipboard).
Screenshots
I guess it is clear enough without...
Client (please complete the following information):
Server (please complete the following information):
Additional context
A very similar bug has been present in the past (just the selected text on the remote machine to be overwritten has been pasted instead of text copied into the clipboard on the local machine, if I remember well). This seem to be a kind of reincarnation of that one...
The text was updated successfully, but these errors were encountered: