Wayland:
wl-paste -p --watch wl-copy -cp
X:
xsel -fin </dev/null
Same result, if u do this u basically can’t select text in any gtk application, i would report this bug to the devs if their website wasn’t retarded requiring the 45th git account with a 19 letter password (like… what? fuck off), i mean it’s not as bad as kde, but damn.
So i was just wondering if anyone happens to have a solution for this? It’s quite annoying.
This doesn’t work because you are using Gnome. The --watch flag requires a compositor that uses wlroots (case in point: the command works as intended on sway). If disabling middle-mouse paste is your goal, then you should look at how to remap the middle button to something else. Granted, I’m not sure if this can be easily done in Gnome (I suspect you’re going to have to define a udev rule for this), but you can look into it.
Source:
$ man wl-clipboard
P/S:
If they allowed anonymous bug reports that don’t require user login, that’s a good way to get spammed, bruh.
I am not using gnome, i am using gtk applications, i’m on hyprland. Which is a wlroots compositor.
And disabling middle mouse button is not the same as disabling the primary clipboard, i still want my middle mouse button to work as a middle mouse button does, without the stupid pasting that nobody under the age of 30 likes.
Well, gtk is the gnome toolkit, so that was why. It’s not a problem with the compositor or wm, it’s a problem with gtk and gtk only.
Since you are using a wm and not a desktop environment, no matter if the issue is with GTK, a GNOME toolkit, the appropriate section would be All WMs.
If you disagree, you could re-categorize.
I don’t really care either way, it’s fine.
Open a terminal and run the command with WAYLAND_DEBUG=1.
$ WAYLAND_DEBUG=1 wl-paste -p --watch wl-copy -cp
Leave the command to run in the terminal. Open up your gtk application and try to copy-paste a bunch of text.
Once you’re done experimenting, terminate the command with Ctrl+C and share the stderr output here.
Here was all i could see of the output in my terminal, assuming that’s what you meant. i just tried to select some text for like a second, it really spat out a lot.
Yup. That’s to be expected since it’s a bunch of debug logs. I’ll try to have a look and see if I can find anything useful in there.
@rabcor This is certainly a strange problem. I read through the logs and, as far as I can tell, the clipboard application is behaving as intended. set_primary_selection(nil) was called every time you make a selection with your mouse, thus clearing your primary selection. On the other hand, I didn’t see any selection(nil) being called, which means the non-primary selections should be left untouched.
Can you try this experiment just to rule out the possibility that the problem is with wl-clipboard.
wl-paste -p --watch wl-copy -cpwl-paste and wl-paste -p.If the clipboard is behaving appropriately, we can expect wl-paste to return the text to you copied and wl-paste -p to return nothing.
Is this the actual behavior?
Step 2 is not possible, literally i cannot select any text in any gtk application.
Lets say i try to select by double clicking, the highlighting thing that shows the selected text appears for milliseconds (like so short i can’t see it unless i am really concentrating to do so)…
Ok here’s what i did.
Nothing is copied$ wl-paste
$ wl-paste -p
Nothing is copied
I believe it may have tried to copy the selected text but because the selection was empty by the point i clicked copy it copied nothing thus pasted nothing, that’s my theory anyhow.
I cannot replicate steps 1-3 now though after trying again (Whenever i run the command, the selection gets deselected instantly now)
This is the best i got.
I believe I have found a clue, I have an alternate approach to disable the primary clipboard in wayland that doesn’t have this effect on gtk applications (the problem with it is that it isn’t 100% effective, it only prevents pasting about 9/10 times)
It looks like this
wl-paste -p --watch wl-copy -p </dev/null
Using that if I click + drag then text is selected normally (well, 9 times out of 10 anyhow… that 1/10 thing it sometimes deselects when I release the left mouse button).
If I double click a word however, it behaves like it does with the -cp command (e.g. the selection highlight only appears for a matter of milliseconds)
However if I double click and then drag, it selects as you would expect.
I haven’t gone through your replies yet, but here’s another idea off the top of my head.
$ gsettings set org.gnome.desktop.interface gtk-enabled-primary-paste false
The caveat is that this should only disable middle-click pasting for gtk applications only (if it even works).
I mean yeah, that does what it says, (interestingly setting it to true doesn’t seem to reverse it though, so primary clipboard is just off in gtk for me now permanently or maybe until i reboot)
But it has no effect on the selection issue, and i need it off in all the other applications too, which includes qt applications and other applications i have no idea what are using like chromium/electron and such.
interestingly, for some applications (like chromium) only wl-copy -cp will actually work.
Yeah. I suspect the issue being application-related as well. The debug logs for wl-clipboard showed the expected behavior.
Are you able to compile a list of applications where the wl-copy method doesn’t work? Perhaps those applications have a common dependency.
Update:
Earlier, I tested the wl-paste method on firefox and it works so far.
I am experiencing the issue in gedit specifically. But I do have thunar around here somewhere and firefox, i could try them.)
Edit: It happens in thunar, not in firefox.
I can confirm this as well. I tested with thunar once again and the behavior is just as you described. I must have accidentally killed the command when I tested thunar earlier.
I have created a convoluted workaround specifically for Hyprland…
#!/bin/sh
#Step 1: Disable primary clipboard for GTK:
# gsettings set org.gnome.desktop.interface gtk-enable-primary-paste false
#Step 2: Add your GTK apps or any apps where you don't want the primary clipboard cleared to the applist variable below (must be the name of the 'class' as shown by hyprctl activewindow)
#Step 3: wl-paste -p --watch /path/to/this/script
applist="thunar gedit kitty"
#Check if current window is a known on applist, and if it isn't, clear primary clipboard.
if hyprctl -j activewindow | jq .class | grep -E "$(echo $applist | sed 's: :\|:g')"; then
exit
fi
wl-copy -cp
This script will when executed according to it’s instructions make sure that the primary clipboard only gets cleared if you are using an app that is not on the list.
It also makes it possible to enable middle mouse pasting for specific apps by adding them to the list, like my terminal, it’s kinda handy actually. now I could feasibly use middle mouse paste in the one god damn place where it makes even a sliver of sense.
The only potential problem with this approach is that you can’t “cross-paste” between windows with the middle button. For example, if you highlight a bunch of text in a GTK app then try to middle-click paste it into your terminal, it won’t work because the primary clipboard will have been cleared. Granted, I can’t really be the judge of whether or not this is an issue. If this approach suits your use case, then it’s probably as a good workaround as any.
Root cause of this problem: The highlight selector of certain gtk applications is directly tied to the state of the primary clipboard. Try this. Put a terminal window and the gtk application side by side. Go the the gtk app and highlight a bunch of text. After that, go to the terminal and run
$ wl-copy -cp
You will see the highlight disappear as soon as that command is run.
Having said that, I think this behavior only affects a subset of the gtk library because not all gtk applications exhibit this behavior (e.g: firefox).
Off the top of my head, here are a few alternative workarounds that I can think of. Please bear in mind that these may or may not work because I don’t really have the time to test them out yet.
Workaround 1: Watch the normal clipboard instead of the primary clipboard. In other words, remove the -p flag in
$ wl-paste -p --watch wl-copy -cp
This will clear the primary clipboard only after you have copied your selection into your normal clipboard. The downside of this approach is that you will still end up middle-pasting if you highlighted a bunch of text but forgot to copy them. If you only highlight text when you intend to copy them, this workaround will be the simplest and cleanest.
Workaround 2: Assign a keybinding to the middle-mouse button to run a custom command. For example, you can bind the middle-mouse button to run wl-copy -cp. In hyprland, you can probably do something like
bind=mouse:274,exec,wl-copy -cp
That way, you can still select into the primary clipboard; it just won’t paste a bunch of text when you accidentally pressed the middle-mouse button (probably). You will have to do some testing to see if the middle button still works as intended in other contexts, of course.
Workaround 3: Instead of clearing the primary clipboard directly, you pipe the contents of an empty file (e.g /dev/null) into the primary clipboard. For example,
$ wl-paste -p --watch wl-copy -p </dev/null
I’m not entirely sure if this will work, tbh. If the -c flag is what’s causing the highlighted text to disappear (not 100% sure about this), then we can try to empty the primary clipboard contents without using the -c flag.
Workaround 4: Use the sxhkd (this works for X11 only) hotkey daemon (or maybe xbindkeys)
Install sxhkd and then add the config file ~/.config/.sxhkd/sxhkdrc with the following contents:
~button2
echo -n | xsel -n -i
~control + c
echo -n | xsel -n -i
~control + x
echo -n | xsel -n -i
Configure sxhkd daemon to autostart, and you should be able to use the middle click button normally without autopasting.