Primary clipboard doesn't work with pure Wayland

[Hi-Angel]

This is a different issue from alike one with XWayland.

A text selected in gnome-terminal does not get pasted into gedit (both are pure Wayland clients).

Steps to reproduce:

1. Open gnome-terminal and gedit.
2. Select a text in gnome-terminal.
3. Try pasting the selected with middle mouse button into gedit.

OS: Archlinux
Sway version: 0.10-1

[ddevault]

There is no primary clipboard in Wayland. Wayland is not x. There is just one clipboard.

[Hi-Angel]

There is no primary clipboard in Wayland.

This is untrue. I remember there was a discussion about adding clipboard to the protocol. And this was added — again, I just checked in gnome-on-wayland, primary selection works.

[Drakulix]

Gnome has added an unstable new primary selection protocol very recently. While support from wlc/sway is certainly not expected, that would actually be nice to have.

[Drakulix]

Update: https://git.gnome.org/browse/mutter/tree/src/wayland/protocol/gtk-primary-selection.xml

[Hi-Angel]

While support from wlc/sway is certainly not expected

I have to disagree, it's one of showstoppers so far to migrating to sway.

[ddevault]

You can be real demanding, you know. Implement it if you want it.

[Hi-Angel]

@SirCmpwn thank you :з Not in the close time though because I have a real big TODO, but anyway.

By the way, I remember a talk on #wayland irc about removing all the "gtk_*" prefixes from the protocol to abstract it. Idk why wasn't it done yet. Though I don't have an idea why would anybody care about the names either…

[Drakulix]

I have to disagree, it's one of showstoppers so far to migrating to sway.

Thats not exactly what I meant. It certainly disrupts my personal workflow, not being able to use such features, that I am used to from using i3 for quite a long time. But it is not essential, was very recently added by gnome and using a full wayland desktop outside of gnome should be expected to be not a very fleshed out experience anyway. There are certainly bigger and much more important TODOs for this project and given the limited time of the developers and contributors, I would not expect this feature to be supported at this time.

That said you request is not unreasonable or invalid. But I would not expect or even demand to see this fixed in the near future.

[TapioT]

If you use fcitx, the clipboard works. I also had problems with my keyboard mapping with xwayland applications, but using fcitx (or ibus) fixed that.

[Hi-Angel]

@TapioT just to be sure, are you saying about primary clipboard, or secondary one?

[TapioT]

I am not an expert in this, but when I copy something from Chromium running on xwayland, I can see the same text in the primary and clipboard but not on secondary (with xsel --output --primary or xsel --output -clipboard). When I paste to Chromium, the text comes from clipboard -- I copied different text to primary, secondary and clipboard and pasted to chromium to see what comes out.

I am running fcitx. Works for me.

[Hi-Angel]

@TapioT I just tested, it didn't work. Here're my step-by-step actions, in case you'd have some idea what gone wrong:

1. I switched to a virtual terminal
2. Executed GTK_IM_MODULE=fcitx QT_IM_MODULE=fcitx sway
3. (sway started) I ran konsole, and started fcitx -d there.
4. In another tab I ran both gnome-terminal and gedit
5. I selected a text in gnome-terminal
6. I pressed with middle mouse into gedit. Nothing get pasted.

[Hi-Angel]

@TapioT by the way, this issue is specifically about pure wayland apps, for XWayland-specific clipboard problems there's another bugreport.

[fpqc]

Answer: Don't use GNOME terminal. Michael Fornay's port of st to pure Wayland sends selected text directly to the clipboard, and I also implemented OSC 52 support (in the clipboard branch) if you use tmux inside it.

Unfortunately there is a minor problem getting st-wayland running on sway, but as always, patches are welcome. GNOME-Terminal is doing it wrong, and so is libvte.

[Hi-Angel]

@fpqc I've chosen gnome-terminal just because it's a pure wayland app. If you've another in mind (as you said that st didn't work under sway), I can test it — but it is very unlikely that anything at all would change, because if you've read messages higher: primary clipboard just not implemented yet. It's just so happened that upon building Wayland protocol devs forgot it, and then Red Hat added primary clipboard as an afterthought extension. As of writing these words AFAIK there's only one mature enough Wayland-compositor to have everything including primary clipboard — Gnome/mutter.

[fpqc]

@Hi-Angel The primary clipboard should not be implemented. It was a terrible idea to start with. The way that st does things is correct: Drag-selection in terminal emulators should save text to the clipboard in Wayland. In other applications, it shouldn't do so. You're much more likely to be able to get st working under sway in the near future than convincing the GNOME people to fix their software. Maybe @SirCmpwn has an obvious patch for sway to make st work, but if not, the incompatibility is coming from using a different version of xdg-shell: michaelforney/st#6

[Hi-Angel]

@fpqc terrible idea, are you serious? That "terrible idea" is the thing that makes me swear every time someone asks me to sit down before PC with Windows to help with something, and I reflexively select text in text-process/editor/widget/anything, and especially putty (where they on Windows had to hack around the missing primary clipboard with something like just copying any selection either on selection, or on press mouse-2).

Primary clipboard allows one to optimize their workflow so that you don't have to press additional keys. E.g. just now I'm helping a buddy, and he pasted an error in the chat, and I use primary clipboard to paste part of the text into a terminal.

Aren't you're using a tiling WM? If you're, I wouldn't expect you to question a necessity of an optimized workflow.

Drag-selection in terminal emulators should save text to the clipboard in Wayland

That would be horrible. Once I had experience of occasionally turning on some option in klipper, that made him to save every selected text into clipboard. I couldn't find anything I explicitly copied, that was actually a mess.

[fpqc]

@Hi-Angel There is no reason why selecting text in a web-browser should copy to the PRIMARY. There is no reason why selecting text in a file manager should set the PRIMARY. There is literally no time you ever want to set a clipboard on selection outside of a terminal emulator.

In st for Wayland, middle click still pastes, but it pastes the Wayland clipboard. Selecting text still sets a clipboard, but it sets the Wayland clipboard instead of of the PRIMARY. The behavior of copying/pasting should be the same everywhere but in terminal emulators, and this is what you get if you use st in Wayland.

There's nothing stopping you from continuing to use Xorg if you really want 9 independent clipboards =p.

[Hi-Angel]

@fpqc well, I am not sure, but if you want examples when it is necessarily: copy a snippet from StackOverflow, copy a snippet from a blog, copy a code from an article, copy ip address from a terminal to a widget, copy a text from lowriter to a mail, copy a text from a mail to lowriter. Literally everything.

It's possible that you don't know — because when I didn't know, I also though "what a stupid idea about primary cliboard" — how it works. It does not copy anything when you select a text. I.e. when you selected a bunch of text, nothing happens. The copy only happens when you press the middle mouse button, not earlier.

[fpqc]

@Hi-Angel I have news for you: That is how the X protocol also handles the Clipboard. It happens for primary & clipboard. However, most terminal implementations I have seen do a strdup when setting a selection buffer, because it means you can just free the selection buffer just in time to assign a new selection, so you do in fact have a memcopy here.

[Hi-Angel]

@fpqc

I have news for you: That is how the X protocol also handles the Clipboard. It happens for primary & clipboard.

Yeah, I didn't know it.

In st for Wayland, middle click still pastes, but it pastes the Wayland clipboard. Selecting text still sets a clipboard, but it sets the Wayland clipboard instead of of the PRIMARY. The behavior of copying/pasting should be the same everywhere but in terminal emulators, and this is what you get if you use st in Wayland.

This approach won't work for multiple reasons. First, it'd annoy users, because they don't expect upon selecting something to lose the copy in secondary clipboard ("Wayland clipboard" for Wayland). Because it's completely new behavior for common actions.

Second, toolkits already have established and working implementation for primary clipboard, and it's used on Wayland too, e.g. by mutter. So this approach would differ from what everyapp does.

Third: just suppose for a second that your approach would be taken by everyone. It would end up in terrible mess, which I occasionally experienced already, as I mentioned in the prev. comment:

Once I had experience of occasionally turning on some option in klipper, that made him to save every selected text into clipboard. I couldn't find anything I explicitly copied, that was actually a mess.

[fpqc]

This is the opposite. You must right click copy or keycombo to get text into the clipboard except when you are selecting from a terminal emulator.

Moreover, middle-click is already overloaded in almost every application. Why overload selected text as well?

[Hi-Angel]

This is the opposite. You must right click copy or keycombo to get text into the clipboard except when you are selecting from a terminal emulator.

I think we're thinking differently here. What I want is a matter of workflow. What you're suggesting is a matter of a very particular app, where devs just decided to not create a popup menu for mouse-2 click. The difference is that in my case it's an old and widely used feature. Whilst in your suggestion, it's an idiosyncrasy of a single app, about which people would forget on every switch to other window.

Moreover, middle-click is already overloaded in almost every application. Why overload selected text as well?

I've not seen a single app where middle click didn't work.

[fpqc]

Middle-click a link in firefox or chromium. Paste will be suppressed and the link will open in a background tab. The reason why you want highlight-to-clipboard in a terminal emulator vs some other program is that the text in a terminal emulator often moves.

[Hi-Angel]

Middle-click a link in firefox or chromium. Paste will be suppressed and the link will open in a background tab.

Okay, I just checked Chromium — it pastes the text. In Firefox it does as well — heck, every time I'm quoting you here, I'm pasting the text with middle mouse button :Ь

I should say, by default Firefox indeed has annoying behavior: if you click into empty space with a link behind primary clipboard, it opens the link. But first, it's not what you described — the paste is never suppressed, it happens only when there's nothing else to do with middle click, i.e. pressing into empty space. Second: I've even seen some people that like it — I don't, so I'm just disabling it once I'm installing Firefox. But FTR: I didn't disable that in Chromium, it just doesn't behave this way.

The reason why you want highlight-to-clipboard in a terminal emulator vs some other program is that the text in a terminal emulator often moves.

I'm glad that I'm using Konsole, which just stops the text movement, if I highlighted something. UPD: sorry, actually, it stops the movement upon scrolling up, not highlighting, but anyway.

[fpqc]

@Hi-Angel Whatever floats your boat then. But if you're going to use something heavyweight and terrible like Konsole, why do you want sway to handle this stuff?

[Hi-Angel]

But if you're going to use something heavyweight and terrible like Konsole, why do you want sway to handle this stuff?

Well, I could say even more to it: right now I'm writing from i3wm with compton making my inactive windows transparent, so at left side of the browser where I'm writing this text, I see a wallpaper through konsole window.

I'm using a tiling WM for the same reason I'm using Emacs with Evil-mode (vim mode), and Firefox with Pentadactyl extension — it's an optimized workflow. So to do something I have to do less actions. I can manage the system mostly from keyboard. And, by the way, if I take the mouse, e.g. to select your comment — the fact that I don't have to additionally press Ctrl+c to copy the text is also an optimized workflow.

[fpqc]

Save the frames, bro. I personally hope the unified clipboard stays as default so I can have my middle mousebutton back. =p

[Hi-Angel]

I personally hope the unified clipboard stays as default so I can have my middle mousebutton back. =p

Honestly, I doesn't see how primary clipboard can mess with what you've described. It's even better for you: no need to write an additional code to copy the selection to clipboard — everything already done by toolkit.

[fpqc]

Yes, I had hoped that the toolkits would be forced to adapt to something sane...

[WhyNotHugo]

I'd also like to +1 this, but try to add some constructiveness to the discussion as well (I really hope this doesn't come out as a rant, because I'm just trying to convey difference perspectives). I get that some people don't like having two selections (I think we all agree that it's 100% personal preference), but personal dislike isn't really a reason to drop a core feature (I say core because it's so important is has a dedicated mouse button!), IMHO.

We currently have apps that unify both Xorg selections (clipboard/primary). Having both means people can use one or two selections, whatever suits them better. The current basically works for everyone. IMHO, we should port the same idea to wayland: have two, but some way of unifying them for those who want to.

Having a single one, means that some people are okay, but the others have no workaround, and permanently lose a very important feature.
Also, one of the reasons for dropping PRIMARY selection, was that there are few middle mouse buttons in the world[source]. This really hasn't been true since early last decade.

Finally, if CLIPBOARD replaces PRIMARY, it's destructive. I constantly have a mental map of what each selection contains. If one deletes the other, it's destructive, and it might lead to irreversible data loss (eg: the data I'd ctrl+x'd somewhere else is gone, forever).
I selected-middleClicked several times writing this, but I recall I've some important data in the CLIPBOARD selection that I'd hate to have lost and have to look for again.

[...] so I can have my middle mousebutton back.

I'm kind of curious what you mean by "have [..] back". It's not like it had some previous usage. The middle mouse button has served for pasting since it's inception, AFAIK (definitely so in the late nineties). Pasting has been that button's main usage (except "open link in new tab", and very specific exception).

---

TLDR:
I'm really okay with it being able to unify both clipboard as an option. But it being the only option (or even the default), is a loss of a core functionality we've had for too many years and will block many from migrating to wayland (even those of use really wanting to!).

[ddevault]

We will implement a primary selection using the GNOME API in addition to the current Wayland clipboard and offer configurable means of synchronizing them with each other and the corresponding x clipboards.

[WhyNotHugo]

@SirCmpwn Glad to hear that! Looks like that will keep everybody happy, thanks!

[akostadinov]

I was surprised to recently see how only few people know and use clipboard managers. This is an essential feature for me because I often times switch between things I have copied/selected. IMO we need a nicely working clipboard manager. Last time I tried it was flaky and I had to switch back to X11. Not sure this is the right place but I think it is very much an important use case to consider when designing copy/paste features.

[interduo]

@akostadinov +1 I select in one place 10+ things and paste in another place. It saves me a lot of time with changing the places of copy and paste. It's main thing i go back sometimes to x11.

[interduo]

What's the status of resolving this issue? Why it's closed?

[ddevault]

We have implemented this in the wlroots branch and it'll land in sway 1.0.

[khughitt]

Thanks for implementing this! Do you know where I can find more information on how to interact with the primary selection in Sway? I checked the man pages, but couldn't find any information on it..

I can now output primary selection with wlpaste -p, but I haven't found a way yet to get it into something like Chromium.

[emersion]

but I haven't found a way yet to get it into something like Chromium.

Not sure what you mean. Middle-click pastes the primary selection.

[khughitt]

Middle mouse is not working for me with latest git commit of sway and wl-roots. Any ideas what could be up?

[emersion]

Does it show up when you run sudo libinput debug-events?

[khughitt]

Nope - middle mouse button clicks do not appear to register there.

[emersion]

Then there's an issue with your hardware. Maybe the middle click button is broken.

[khughitt]

Ha! Turns out you are right -- The button does still work, but the middle mouse button is much less sensitive than I remember. Pushing it a bit more forcefully did the trick.

Thanks for the suggestion about libinput debug-events! I didn't know that command existed.

[drrossum]

Thanks for implementing this! Do you know where I can find more information on how to interact with the primary selection in Sway? I checked the man pages, but couldn't find any information on it..

I can now output primary selection with wlpaste -p, but I haven't found a way yet to get it into something like Chromium.

I would like to ask the same question.

I used a keybinding in XMonad for pasting the primary selection buffer into the active window. How can I do this in sway? I tried using a symbind to wl-paste -p but the output sent by wl-paste does not get picked up by the active window.

[emersion]

I used a keybinding in XMonad for pasting the primary selection buffer into the active window.

How did that work under X11?

the output sent by wl-paste does not get picked up by the active window.

wl-paste retrieves the current selection.

[drrossum]

In XMonad this is done using two modules:

1. XMonad.Util.Paste sends key presses to windows
2. XMonad.Util.XSelection accesses X Window's mouse selection

wl-paste does already have functionality 2. What is outstanding (or at least I can't find the info) is a way to do 1, i.e. send the buffer to the active window as key presses. I guess, an alternative to 1 would be to send the buffer to the active window as mouse-paste buffer, i.e. discarding the mouse pointer location.

[drrossum]

I see that this only tangentially relates to the original issue. Should I open a new issue/feature request?

[emersion]

(1) already has an issue: #1779

There pointer part is already implemented: https://github.com/swaywm/sway/blob/master/sway/sway-input.5.scd#L171

[Flashwalker]

We will implement a primary selection using the GNOME API

How about KDE?
Has anyone found a solution to this issue?
Like the middle mouse insert the primary buffer?
Also in terminal by Shift+Insert?

[emersion]

This issue is very old. The GNOME API (gtk-primary-selection) has been long deprecated and removed, replaced by the standard one (wp-primary-selection).

[WhyNotHugo]

That would be: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/primary-selection/primary-selection-unstable-v1.xml