sway: Primary clipboard doesn't work with pure Wayland

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.

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

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 <kbd>ctrl</kbd>+<kbd>x</kbd>'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!).

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

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

While support from wlc/sway is certainly not expected

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

@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.

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.

@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.

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.

@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 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: https://github.com/michaelforney/st/issues/6

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

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 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.

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.

@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…

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