Bug 422426

Just to clarify on the GTK situation.

GTK does not implement zwp_primary_selection they implement a forerunner gtk_primary_selection. Basically identical but with a different name.

GTK devs have said they would be willing to use the newer one within the GTK3 lifespan. At which point there's no point us implementing that.

We still need our bridge though :)

Perhaps this is the cause of this bug I'm seeing in Wayland sessions.

How to reproduce:
1. select any text in a Qt app such as konsole or kate
2. middle-click in a GTK app such as Chrome or Tilix

Expected result: pastes the text selected at (1)
Actual result: pastes the last selection made in any GTK app

Is there any hack / workaround we could put in place if GTK takes their time to add zwp_primary_selection?

This is quite a showstopper for moving to Wayland, at least for me.

(In reply to bernie from comment #3)
> Is there any hack / workaround we could put in place if GTK takes their time
> to add zwp_primary_selection?
> 
> This is quite a showstopper for moving to Wayland, at least for me.

Same here - I use this feature so much in my day-to-day work that I cannot switch to Wayland from X, yet.

What's the problem now?

a) Xwayland bridge does not exist.
b) GTK Wayland clients do not support zwp_primary_selection.

Or both?

Solution for (a) is adding the bridge, solution for (b) is to talk to someone from Gnome/GTK team to implement it.

How hard would it be to implement the legacy GTK version of the protocol in addition to the standardized version? I assume they only differ by naming, don't they? So it should not be too hard to support the legacy version, or is it?

Both.

Bridge as you say is simple just missing but I have a pending rewrite of the brige to get rid of the internal connection, so I want to finish that first. Then it should be just a few lines.

I had spoken to someone from the GTK team about implementing it. 
Paraphrasing the response it was "we should eventually, patches welcome"

>So it should not be too hard to support the legacy version, or is it?

Not hard, but it'd take about as much effort as just patching GTK ourselves, so it's where I'd rather see time spent.

Update on the GTK situation: according to GNOME/gtk#2591 (https://gitlab.gnome.org/GNOME/gtk/-/issues/2591), support for the standard protocol has landed and will be shipped in 3.24.23 and 3.99.2/4.0.

I have GTK 3.24.23 and all of KDE built from git (synced yesterday), but primary-selection still isn't working between chromium and konsole.

Is there a way to inspect the wayland protocol?

Ok, the patch adding zwp_primary_selection didn't land on the gtk-3-24 branch in time for the 3.24.23 release:

 https://gitlab.gnome.org/GNOME/gtk/-/issues/2591#note_961946

GTK devs say on https://chat.gnome.org/channel/gtk that there aren't any more gtk3 releases planned until after gtk 4.0 is out. Instead of waiting, they recommend requesting a distro patch.

So I went ahead and filed one for Arch Linux:
https://bugs.archlinux.org/task/68667

gtk3-3.24.27 includes support for primary-selection-unstable-v1 (*), and yet middle-click paste between gtk and qt apps still doesn't work with plasma 5.21.2.

How could I help debug this issue?

(*) https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2627

Perhaps it doesn't work because this followup change is missing on the gtk-3-24 branch:
  https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2630

Vlad seems to have found the root cause in GTK:
 https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2630#note_1065234

Now there's a GTK bug:
https://gitlab.gnome.org/GNOME/gtk/-/issues/3791

This comment has some more detail:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2630#note_1065144

Can anyone test https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3357 and confirm that it fixes the issue on kwin?

As for GTK 3 and 4 this should now be fixed by the following MRs:

https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3357
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3374
https://invent.kde.org/plasma/kwayland-server/-/merge_requests/216

(I haven't tested yet, but thanks for the fixes and for the heads up, both are much appreciated o/ ).

Since all three of those are merged, does this mean that full primary selection functionality with GTK apps is now achieved?

(In reply to Nate Graham from comment #19)
> Since all three of those are merged, does this mean that full primary
> selection functionality with GTK apps is now achieved?

If I understood Vlad correctly, then yes :)
Would be good if somebody could confirm this - and also test Firefox if possible.

Awesome, let's mark as fixed and re-open if anyone finds it still broken. Great work Robert and Vlad! Robert, do you know what GTK version your merge requests will be released with?

(In reply to Nate Graham from comment #21)
> Awesome, let's mark as fixed and re-open if anyone finds it still broken.
> Great work Robert and Vlad! Robert, do you know what GTK version your merge
> requests will be released with?

That would be 4.2.x/4.3 and 3.24.29 :)

However, that's actually not what this bug is about IIUC - Xwayland still needs a helping hand from kwin.

(In reply to Robert Mader from comment #22)
> That would be 4.2.x/4.3 and 3.24.29 :)
> 
> However, that's actually not what this bug is about IIUC - Xwayland still
> needs a helping hand from kwin.
What do you mean exactly? "that" == what?

(In reply to Nate Graham from comment #23)
> What do you mean exactly? "that" == what?

The bug title is "Implement Wayland Primary Selection Protocol bridge with XWayland", which actually has little to do with "make primary selection work in the GTK Wayland backend" apart from both being about primary selection.

Primary selection will still not work between QT-Wayland and e.g. Chromium or Pidgin. In order to fix that kwin will need to translate between primary selection of Wayland and X11 - that's not yet done, so the bug should get reopened.

I/we just high jacked this bug and talked about the protocol not working between QT-Wayland and GTK-Wayland because it (this bug) was linked in the GTK issue :)

Oh okay, sorry.

Seems related to Bug 436246.

*** Bug 440706 has been marked as a duplicate of this bug. ***

This is more of a regression than a wish: in X11, users were able to copy-paste across all apps. Once they switch to a Wayland session, Qt5 and GTK3 apps switch to Wayland native, while several other popular apps use XWayland's legacy protocol.

Copy-pasting not working between the two groups breaks very basic workflows. For me, it's usually copying text between Chrome and Konsole. This is why I'm reluctant to migrate to Wayland until this is fixed (or until all the apps I use daily have switched to Wayland).

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1272

Git commit 6104dc50cfa4cfa6467029dfdad17c9848dc225c by David Redondo.
Committed on 19/08/2021 at 06:46.
Pushed by davidre into branch 'master'.

xwl: Sync primary selection

Syncs the primary selection from wayland to X and from X to wayland.
Instead of doing it through the internal connection like the clipboard,
this sets/reacts to changes in SeatInterface::prrimarySelection directly.
FIXED-IN:5.23

M  +1    -0    src/atoms.cpp
M  +1    -0    src/atoms.h
M  +1    -0    src/xwl/CMakeLists.txt
M  +3    -1    src/xwl/databridge.cpp
M  +2    -0    src/xwl/databridge.h
A  +209  -0    src/xwl/primary.cpp     [License: GPL(v2.0+)]
A  +69   -0    src/xwl/primary.h     [License: GPL(v2.0+)]
M  +1    -1    src/xwl/selection_source.h

https://invent.kde.org/plasma/kwin/commit/6104dc50cfa4cfa6467029dfdad17c9848dc225c

Please make the middle-click paste feature optional, at least for Wayland (Bug 441668).

Thank you for taking the time to implement this, David.
Will this ship with 5.23?

(In reply to Bernie Innocenti from comment #32)
> Thank you for taking the time to implement this, David.
> Will this ship with 5.23?

Just noticed the tag in the commit msg: FIXED-IN:5.23

I would also like middle-click paste to be optional. I use middle click regularly, but the fact that it now pastes is unpleasantly unexpected.