Bug 476522

I would like to add some info I wrote in my first effort to document this bug:
---
There seems to be some confusion in regards to the current state of being able to copy/paste from eclipse (2023-09) to:
kde apps like:
konsole
kate
kwrite
and qt-creator (probably more).
First I would like to link to a recent issue created in the eclipse github where this issue is already confirmed and by one of the developers:
https://github.com/eclipse-platform/eclipse.platform.swt/issues/851

The current gtk-version in kde-Neon is based on Ubuntu-LTS (2022.04) and is
gtk v3.24.33 (the version before any wayland clipboard patches).
So I have to strongly disagree with the statements:
>> *not* present in
> > KDE Neon or Ubuntu LTS.
in the closed thread thread: https://bugs.kde.org/show_bug.cgi?id=431100

Today on a standard kde neon setup it is not possible to copy and paste between any of the above listed
kde apps in a wayland session.
However as stated in the github thread I have linked to the issue is partially solved in gtk versions 3.24.34 and 3.24.36.
Manually recompiling and upgrading the gtk packages in kde-neon to the newest from mantic (23.10) gives version 3.24.37.
This adds the functionality of being able to copy from eclipse to the above mentioned apps.
However it is still not possible to paste from these apps into eclipse.

I have also tested on fedore KDE 38 and kubuntu 23.10 which also run gtk 3.24.37.
Same result you can now copy From eclipse, but not paste TO eclipse.
the wayland clipboard illustrates what the problem is:

With all the above mentioned apps selection and right clicking copy gives the result:
text/plain
text/plain;charset=utf-8
and no paste functionality in eclipse.
running the command:
wl-paste -n -t text/plain | wl-copy -t STRING
shows the result:
(base) mib@neon-ws:~$ wl-paste -n -t text/plain | wl-copy -t STRING
(base) mib@neon-ws:~$ wl-paste -l
STRING
text/plain
text/plain;charset=utf-8
TEXT
STRING
UTF8_STRING

and makes it possible to paste in eclipse.

This bug is also a possible unresolved duplicate:
https://bugs.kde.org/show_bug.cgi?id=448511

I just want to correct that the latest gtk version is v3.24.38 not 3.24.37 as I have written.

As I've noted in the previous bug 43110 comment 9 (https://bugs.kde.org/show_bug.cgi?id=431100#c9), the issue essentially boils down to Eclipse not supporting Wayland clipboard content types (RFC-1341 types).

The GTK3 fix was that when an application uses the GTK dynamic library on Wayland and copies data with the "STRING" or "UTF8_STRING" X11 types, GTK automatically also adds the RFC-1341 "text/plain" and "text/plain;charset=utf-8" thereby enabling forward compatibility - Eclipse can now copy into Wayland apps. The reverse is now also handled by other GTK sender apps as well - a GTK app will copy text content with the advertised Wayland (RFC-1341) types and in addition will also advertise the X11 "STRING" and "UTF8_STRING" content types.

Why was no forward compatibility added to the receiving end of the GTK clipboard implementation? I'm going to assume its a consequence of both laziness and carelessness about other parts of the Linux ecosystem: implementing read compatibility is both harder than the write compatibility (and maybe requires API changes - so apps need to opt-in) and also unneeded if all the other apps are GTK apps as well (which, there sure are if you are a GNOME developer).

The issue reported here is that KDE applications that use the QClipboard's default `setText()` API to copy data to the clipboard (https://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qclipboard.cpp?h=dev#n297), and that API only advertises "text/plain" (https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qmimedata.cpp?h=dev#n394).

The correct way to fix this issue is to introduce X11-backward-compatibility to QClipboard - like they did in GTK - by having it's `setText()` method also put in "STRING" data like so:

  data = new QMimeData;
  data->setData("STRING"_L1, text.toUtf8());
  setMimeData(data, mode);

IMO, this is going to be a hard sell to Qt developers.

The other alternative is to have every KDE app, after calling `QClipboard::setText` also immediately set up the `QMimeData` object above and call `QClipboard::setMimeData` - which is what `QClipboard::setText` is supposed to help with - which at this point one must wonder why not instead write a KClipboard class that workaround this issue (and others) with QClipboard.

I don't see that we workaround that in all applications. Either it is worked around in Qt or the other people must fix that.

Well I thought of attempting to do it myself and with success:
https://github.com/eclipse-platform/eclipse.platform.swt/pull/863
I also managed to provide a fix for copying from Eclipse to KDE/QT apps in wayland... 
I expect the fixes will be released in eclipse 2023-12
Then Eclipse clipboard functionality for text/plain:utf8 will be fully functional under wayland :-)
This bug report can be closed.

btw the fix: https://github.com/eclipse-platform/eclipse.platform.swt/pull/863
works with gtk 3.24.33
so no need for the gtk update

I can confirm that this issue is fixed in Eclipse integration build I20231108-0600, so I expect the fix will be in Eclipse 2023-12M3 and in the official 2023-12 release.

Thanks a lot!

@Oded Arbel
Thank you for your info.
However I'm curious as how the merge already  can be in the pipeline as the original PR was build successfully but the PR then needed
to be force pushed several times and then the final PR merge build ended up in a failed state ?
 https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-863/lastBuild/console

(In reply to Michael Brown from comment #10)
> However I'm curious as how the merge already  can be in the pipeline as the
> original PR was build successfully but the PR then needed
> to be force pushed several times and then the final PR merge build ended up
> in a failed state ?

OK, my bad - I saw that the PR was merged to master, and I saw an integration build from the same day - so I killed my workaround script and tried the integration build and it appeared to be working. What I just found out is that I had two workaround scripts running, and with one remaining active - it is what caused the test to appear to be successful.

I'll continue to monitor the integration builds and will update the ticket status once I can *correctly* verify the issue has been fixed.

@Oded Arbel
I'm told repeatedly by the main developers of swt eclipse that:
"your patches were merged yesterday and there has been a successful build since then thanks to . You can just update to latest I-Build or download"
However I have yet no idea yet of what updating to the latest I-Build means ...:-)
https://github.com/eclipse-platform/eclipse.platform.swt/issues/868#issuecomment-1804359275
Be sure to let me know when you can confirm that the wayland clipboard fixes have arrived in the pipeline.

BTW
https://github.com/eclipse-platform/eclipse.platform.swt/commits/master

(In reply to Michael Brown from comment #12)
> However I have yet no idea yet of what updating to the latest I-Build means

Here's how I test:

1. I go to https://download.eclipse.org/eclipse/downloads/index.html
2. Under "Integration Builds" there's a list of builds, ordered by date, descending. I pick the first (latest) that doesn't have scary red exclamation points. ATM it is I20231109-0710, and click that.
3. In the page that opens, under "Platform Runtime Binary", I download the "Linux (64 bit version)", and extract it to somewhere useful on my system - I like to maintain a bunch of Eclipse installations under ~/.local/eclipse, so I extract the tarball there, then rename the newly created "eclipse" folder to "eclipse-<NAMETHISINSTALL>", then update the eclipse menu entry in ~/.local/share/applications/eclipse.desktop to point to the right one).
4. Launch the "eclipse" binary from the new installation. It would probably not have any useful tool other than a plain text editor - which should be enough to test copy and paste with.

I can now verify that I20231109-0710 supports Wayland paste - I can paste into that installation, and if I close it and open the older installation, I cannot paste into it.

If you want to continue working with the integration test build - you can, just go to "Help" -> "Install new software" and install all the tools you need into the integration build. It should also automatically update to the new 2023-12 release when it is published.

(In reply to Oded Arbel from comment #14)
> (In reply to Michael Brown from comment #12)
> > However I have yet no idea yet of what updating to the latest I-Build means
> 
> Here's how I test:
> 
> 1. I go to https://download.eclipse.org/eclipse/downloads/index.html
> 2. Under "Integration Builds" there's a list of builds, ordered by date,
> descending. I pick the first (latest) that doesn't have scary red
> exclamation points. ATM it is I20231109-0710, and click that.
> 3. In the page that opens, under "Platform Runtime Binary", I download the
> "Linux (64 bit version)", and extract it to somewhere useful on my system -
> I like to maintain a bunch of Eclipse installations under ~/.local/eclipse,
> so I extract the tarball there, then rename the newly created "eclipse"
> folder to "eclipse-<NAMETHISINSTALL>", then update the eclipse menu entry in
> ~/.local/share/applications/eclipse.desktop to point to the right one).
> 4. Launch the "eclipse" binary from the new installation. It would probably
> not have any useful tool other than a plain text editor - which should be
> enough to test copy and paste with.
> 
> I can now verify that I20231109-0710 supports Wayland paste - I can paste
> into that installation, and if I close it and open the older installation, I
> cannot paste into it.
> 
> If you want to continue working with the integration test build - you can,
> just go to "Help" -> "Install new software" and install all the tools you
> need into the integration build. It should also automatically update to the
> new 2023-12 release when it is published.

Thanks for the info:
> I can now verify that I20231109-0710 supports Wayland paste - I can paste
> into that installation, and if I close it and open the older installation, I
> cannot paste into it.
The fix I made also includes wayland copy functionality.
So that that there now is full wayland copy/paste clipboard support in Eclipse for the 2023-12 release pipeline.

(In reply to Michael Brown from comment #15)
> The fix I made also includes wayland copy functionality.
> So that that there now is full wayland copy/paste clipboard support in
> Eclipse for the 2023-12 release pipeline.

In copying functionality, I don't see a different behavior with the new build - `wl-paste -l` shows an almost identical output with the old build, except that the new build has the type "text/plain;charset=utf-8" listed twice. I'm guessing that now both the SWT code advertises the Wayland-mandated type, as well as the GTK Wayland compatibility workaround. But it works fine, so 🤷 LGTM.

(In reply to Oded Arbel from comment #16)
> (In reply to Michael Brown from comment #15)
> > The fix I made also includes wayland copy functionality.
> > So that that there now is full wayland copy/paste clipboard support in
> > Eclipse for the 2023-12 release pipeline.
> 
> In copying functionality, I don't see a different behavior with the new
> build - `wl-paste -l` shows an almost identical output with the old build,
> except that the new build has the type "text/plain;charset=utf-8" listed
> twice. I'm guessing that now both the SWT code advertises the
> Wayland-mandated type, as well as the GTK Wayland compatibility workaround.
> But it works fine, so 🤷 LGTM.

Yeah I found it necessary to also do the paste fix in eclipse to cater for the ubuntu 22.04 distributions that will be stuck in gtk v3.24.33
that is without the gtk workaround.
I'm running one of those: KDE Neon on my preferred workstation
I guess you are running something with a newer gtk version ?

(In reply to Michael Brown from comment #17)
> I guess you are running something with a newer gtk version ?

I'm running lunar with the Neon repositories.