CopyQ
CopyQ copied to clipboard
hluk
Copyq is delaying and pasting multiple times when I am using Gnome on Ubuntu 20.04.
Every time I paste something using Copyq on Ubuntu 20.04 with Gnome, the Copyq delays and paste the selected text multiple times. The gif below shows you how to reproduce the problem:
https://user-images.githubusercontent.com/6320673/128718917-67a8fa1f-caff-481c-a15f-f085a791f4ed.mp4
- Copyq 4.10
- Ubuntu 20.04
Hmm, I cannot view the screencast in the description (it says "file is corrupt").
This bug happens to me as well (Ubuntu 20.04)
@hluk By the way, this app is awesome 😃
Hmm, I cannot view the screencast in the description (it says "file is corrupt").
It is strange. It seems that some people could see the video. I short words, Copyq is pasting multiple times and having some lag in ubuntu 20.04.
It is strange. It seems that some people could see the video.
Passing the video URL to a media player works:
mpv 'https://user-images.githubusercontent.com/6320673/128718917-67a8fa1f-caff-481c-a15f-f085a791f4ed.mp4'
It seems that the app gets completely stuck while it simulates Shift+Insert. Could be a bug in the window manager - maybe something to do with the minimize/hide window animation.
You can try increasing wait time before pasting (e.g. 150 milliseconds):
copyq config window_wait_after_raised_ms 150
filename=$(basename -- "$filename##*.")
filename=$(basename -- "$filename##*.")
filename=$(basename -- "$filename##*.")
filename=$(basename -- "$filename##*.")
It still doesn't work. The above text was copied from CopyQ hitting Enter once. Sometimes it's more duplicates, sometimes less. The CopyQ window quickly minimizes and the target window gets frozen, I can't type anything for a couple of seconds
You can also try setting window_key_press_time_ms to 0 (but it could cause problem with some apps like Chrome; default value is 50 ms on Linux):
copyq config window_key_press_time_ms 0
You can also try setting
window_key_press_time_msto0(but it could cause problem with some apps like Chrome; default value is 50 ms on Linux):copyq config window_key_press_time_ms 0
I tried it and doesn't work.
I discovered an important detail. This error only occurs using Gnome.
I am facing this problem on BSPWM running on Arch Linux as well. It experiences some delay and then pastes 10-15 times
I discovered an important detail. This error only occurs using Gnome.
I am facing this problem on BSPWM running on Arch Linux as well. It experiences some delay and then pastes 10-15 times
Recently I'm seeing the same issue with the same setup (bspwm + archlinux)
I am, and have been, seeing this issue in Linux too. It does not happen all the time (not anywhere near all the time) but I just had CopyQ paste something 20 time when I clicked on the text to paste within CopyQ.
NOTE that the last line of the text is supposed to be
sudo systemctl restart pure-ftpd
and that CopyQ immediately starts over again with the first line
#!/bin/bash
making the line read
sudo systemctl restart pure-ftpd#!/bin/bash
I will try the suggested config file modifications.
Also confirming this issue on Manjaro Linux with Gnome 42.4 (X11).
Doesn't happen all the time, and the number of times that the text gets pasted is not fixed (might be 3-4 times - might be like 30 times).
I have a possible fix.
You can install the Flatpak image with the fix using the instructions in the latest flathubbot comment at: https://github.com/flathub/com.github.hluk.copyq/pull/45
Can anyone check if pasting works well with the new Flatpak image?
Unafortely right now, I am unable to test because I am using Linux Mint. So I am not using Gnome. I will try to test it on a machine of a friend.
I've tested but the delay still happening.
Which app version and OS/desktop-environment? Is this happening with the latest Flatpak?
If this is a bug in CopyQ, the only place I see could cause this is at XTestFakeKeyEvent() or XSync() is called.
I have another possible fix that removes the XSync() call in the middle of simulating key press and release (#2116).
I cannot reproduce this so I would appreciate if someone can test the Flatpak build here: https://github.com/flathub/com.github.hluk.copyq/pull/50
Had the same issue. And I am sure the initial bug might have been due to an bug in the code which has been since fixed. But I have found that if you don't set a proper limit for how many entries to save then that causes slight delay too. Additionally if you have set any global shortcut for Ctrl + V that occasionally also causes an delay and problems similar to as described in this issue.
Is it possible to disable the "paste on enter" and instead just have enter change the current clipboard selection? This would require the the user to use the normal CTRL-V to actually perform the paste. I realize that would require an extra keypress, but that's better than having data pasted twice.
Is it possible to disable the "paste on enter" and instead just have enter change the current clipboard selection?
@sirianni Disable "Paste to current window" option in History configuration section in Preferences.
Thank you! I searched all the preferences and overlooked that section!
On Thu, Dec 14, 2023 at 1:31 AM Lukas Holecek @.***> wrote:
Is it possible to disable the "paste on enter" and instead just have enter change the current clipboard selection?
@sirianni https://github.com/sirianni Disable "Paste to current window" option in History configuration section in Preferences.
— Reply to this email directly, view it on GitHub https://github.com/hluk/CopyQ/issues/1729#issuecomment-1855226012, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC5C5UPXKXR3R5PM3EHGA3YJKML7AVCNFSM5B2C4PH2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBVGUZDENRQGEZA . You are receiving this because you were mentioned.Message ID: @.***>