That bug was also reported on eclipse bugzilla as https://bugs.eclipse.org/bugs/show_bug.cgi?id=570026

Did the text end up in the clipboard after you copied it? You can check with the System Tray Clipboard applet.

If Eclipse running as an XWayland app or a native Wayland app?

The eclipse graphic library is eclipse.2020.12.Release/eclipse/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.2.0.v20200915-1442/eclipse_11201.so .

Normally eclipse is run as a native wayland app. At least I have the wayland icon on top left of eclipse window. 

I can copy paste in both direction between konsole and firefox and between eclipse and firefox.

When i copy text from konsole, the tray clipboard applet sees it and i can copy and paste.
but i cannot paste contents to eclipse java editor view.
 
When i copy something from eclipse the system tray see it sometimes - from package explorer view, content from eclipse configuration window for example, i copied and pasted the path of the graphic library given above without any trouble -. 

Contents copied and pasted from java editor view and outline view do not appear in the system tray clipboard applet.

Thanks for the info. Based on that, I think this is a bug in Eclipse, rather than somewhere in any KDE software. Can you file a bug report on Eclipse and see what they say about it? Thanks!

The discussion is pursued on eclipse-bugzilla. Given check that have been made with gedit the roblem apear to be some kind of concurrency between kwin-wayland clipboard and gtk-wayland clipboard.

gedit and firefox seem to work around that and eclipse, that appears to be NOT TESTED ON RECENT KDE VERSION, don't.

Even if a part of that problem must be solved within eclipse, there is still the problem of that concurrency between the two clipboard management that can lead to kwin-wayland crash.

further discussion goes here:
https://bugs.kde.org/show_bug.cgi?id=431327

The Eclipse Bugzilla does not seem to have the bug that was linked in comment 1 - clicking on that link leads to an error about invalid bug ID.

The original issues is still prevalent: On Wayland, copying text from Eclipse does not show up in Klipper and cannot be pasted into KDE applications - for me this is always the case, it never worked on Wayland.

The workaround I have, for now, is that after copying in Eclipse - I open gedit, paste it there, copy it from gedit and then it is available to KDE applications.

I believe the issue is the mime types Eclipse advertises for its clipboard content - when copying from Eclipse, the following mime types are offered:

text/rtf
TEXT/RTF
application/rtf
UTF8_STRING
STRING
SAVE_TARGETS

All other applications I've used, whether KDE applications or not, offer at least `text/plain` and `text/plain;charset=utf-8`. Using the wl-clipboard tool (after messing with it a bit, the default config sticks in `text/plain` if you try to use any text type), I can see that if I put something into the clipboard that advertises just the types `STRING`, `TEXT` or `UTF8_STRING` - klipper won't show it and KDE apps would not paste it.

As far as I understand, these types should be equivalent to `text/plain` and non-KDE applications seem to handle them fine.

I have no idea where this basic behavior is implemented - if anyone can point me in the right direction, I'd be glad to offer a patch.

Did more research - the problem is likely originates in Qt, where applications I reviewed are basically doing

QApplication::clipboard()->mimeData(QClipboard::Clipboard)->text()

which, as can be seen here [https://codebrowser.dev/qt5/qtbase/src/corelib/kernel/qmimedata.cpp.html#406] is implemented by finding either a `text/plain` or `text/plain;charset=utf-8` mime type and returning its content, otherwise - returning empty text.

From what I've been able to understand the `STRING`, `TEXT` and `UTF8_STRING` types are holdovers from X11 (e.g. X11 6.4 ICCCM p2.7.1) and should not be expected to be applicable to Wayland. One might say that this puts the ball back in Eclipse's court - as it only offers RTF options for Wayland specified mime types - except that pasting from Eclipse does work in GTK apps.

Assuming GTK apps do allow pasting from Eclipse on Wayland by implementing "backwards compatible" X11-typed clipboard handling (I haven't checked, but gedit - for example - definitely does not support RTF types for pasting, so it can only use the STRING types) - should we:

1. Work to implement such backward compatibility support for Qt-based apps - this will required adding workaround code to each application that uses QClipboard and QMimeData
or
2. Petition Eclipse to be a more upstanding Wayland citizen

I would definitely prefer the later, but as Eclipse devs are horribly averse to external work items (I've tried many times in the past), I think we should come up with an alternative.

Last comment for the day (I apologize for the bug spam - I'm trying to research this issue and I don't want to lose the results):

I don't think Eclipse is to blame for this problem - they just use GTK calls directly (https://github.com/eclipse-platform/eclipse.platform.swt/blob/975011388a62584b52141fff2fa5c3d16ff4ec33/bundles/org.eclipse.swt/Eclipse%20SWT/gtk/org/eclipse/swt/widgets/Text.java#L760).

Possibly the problem is that they build with an old version of GTK - supposedly Eclipse supports GTK 4, but the latest builds from eclipse.org are using GTK 3.22.30 (which is not even current for GTK 3 - the current minor version is 3.24, which was released in 2018 and had a lot of Wayland work). It does appear to use dynamic linking, and on Neon jammy, Eclipse seems to be running with the system's 3.24.34 - the same library gedit uses, and gedit does have proper text mime types on its clipboard content, which from what I can find, this is not a gedit hack: this is the default GTK text view implementation. ¯\_(ツ)_/¯

Maybe hacking around QMimeData is still a viable option?

BTW, for people suffering from Eclipse's clipboard deficiency and want a workaround: I have installed the wl-clipboard package and then use the following script as a daemon (run it as a background task in your shell, set up a SystemD user service, whatever):

```
#!/bin/bash

case "$1" in
listen) wl-paste -w "$0"; exit;;
esac

avail_types="$(wl-paste -l)"

if grep -q STRING <<<"$avail_types" && ! grep -q text/plain <<<"$avail_types"; then
        wl-paste -n -t STRING | wl-copy -t text/plain
fi
```

When run as '<script> listen', the script uses the wl-paste and wl-copy command line tools from wl-clipboard to watch the Wayland clipboard and if it sees the clipboard advertising "STRING" but not "text/plain", it immediately creates a "text/plain" copy of the "STRING" clipboard entry.

This does kill the RTF clipboard content advertised by Eclipse, so if you need that - don't use the "listen" mode, just execute the script (with no parameters) every time you need a one-off text copy of the clipboard content.

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

Created attachment 153393 [details]
attachment-21461-0.html

bug still exists in sid from today (2 november 2022) and eclipse 
Version: 2022-09 (4.25.0) Build id: 20220908-1902.

side note: copying version and build from eclipse about dialog to 
thunderbird works, but not to Kate.

Dietmar

Am 31.10.22 um 19:04 schrieb Nate Graham:
> https://bugs.kde.org/show_bug.cgi?id=431100
>
> Nate Graham<nate@kde.org>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Version|20.08.3                     |5.26.2
>            Component|copy-paste                  |Clipboard
>              Product|konsole                     |plasmashell
>     Target Milestone|---                         |1.0
>             Assignee|konsole-devel@kde.org        |plasma-bugs@kde.org
>

It look like not kde bug - https://github.com/eclipse-platform/eclipse.platform.swt/issues/421
and it is fixed in gtk3-3.24.36 (https://bugzilla.redhat.com/show_bug.cgi?id=2151603)

I could reproduce this issue in the past, but I currently can't reproduce this issue on Neon unstable with Plasma 5.28.80, Frameworks 5.103.0, Qt 5.15.8, Eclipse 4.25.0 (2022-09) and gtk3 3.24.34, so marking this issue as fixed UPSTREAM.

Same here with Eclipse 4.26, Plasma 5.26.90

Seems so, the bug can be closed


Am 24.01.23 um 15:56 schrieb Oded Arbel:
> https://bugs.kde.org/show_bug.cgi?id=431100
>
> Oded Arbel <oded@geek.co.il> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>               Status|CONFIRMED                   |RESOLVED
>           Resolution|---                         |UPSTREAM
>
> --- Comment #15 from Oded Arbel <oded@geek.co.il> ---
> I could reproduce this issue in the past, but I currently can't reproduce this
> issue on Neon unstable with Plasma 5.28.80, Frameworks 5.103.0, Qt 5.15.8,
> Eclipse 4.25.0 (2022-09) and gtk3 3.24.34, so marking this issue as fixed
> UPSTREAM.
>

kde neon 
plasma: 5.27.7
framework: 5.108.0
Qt.: 5.15.10
Wayland

eclipse: 2023-06 (4.28.0)
gtk: 3.24.33-1ubuntu2
eclipse relevant conf:
org.eclipse.swt.internal.gtk.theme=Breeze
org.eclipse.swt.internal.gtk.version=3.24.33

Copy paste does not work.

(In reply to Oded Arbel from comment #15)
> I could reproduce this issue in the past, but I currently can't reproduce
> this issue on Neon unstable with Plasma 5.28.80, Frameworks 5.103.0, Qt
> 5.15.8, Eclipse 4.25.0 (2022-09) and gtk3 3.24.34, so marking this issue as
> fixed UPSTREAM.

I want to retract what I said above. It may have been the Plasma 6 pre-release that I was running at the time, or something else, but currently with: Plasma 5.27.7, Frameworks 5.109.0, Qt 5.15.10, Eclipse 4.28.0 (2023-06) and gtk 3.24.37 (I'm not 100% sure the GTK version is correct, but this is what Eclipse's libswt-pi3-gtk-4960r6.so dynamically links to, on my system) - I can definitely see this problem.

To reiterate:
When running Wayland, copying text from konsole, or from many different KDE applications (I've tested yakuake, kate, gwenview, dolphin, lokalize and okular), trying to paste into Eclipse does not work: Eclipse behaves as if there's nothing in the clipboard.

The problem is that KDE applications, when copying text, offer the clipboard content with the MIME content types `text/plain` and `text/plain;charset=utf-8` (and sometimes additional MIME types), while Eclipse will only accept clipboard content published with the non-MIME types 'STRING', 'UTF8_STRING' and 'TEXT'. This is not a GTK+ thing - gedit has no problem pasting KDE Wayland clipboard content, even when running in X11 mode.

When GTK+ apps put text into the clipboard, they set the content types for the clipboard item with the legacy X11 types as well as the new types - and everything works great: KDE applications have no problem reading that, as well as legacy applications. I think this it the change that needs to be done.

Unfortunately, as far as I can tell, KDE applications generally use the Qt clipboard API and do not use any KDE/Plasma specific API, so any "global" fix has to be done at the Qt level, IMO.

Note about the upstream fixes that have been pointed out before (the SWT issue and the RedHat bug report pointing at the GTK+ patch) - these appear to be exactly about the current behavior of GTK+ apps: publishing both legacy and MIME types to the clipboard. Specifically in the SWT issue they say that as GTK+ now both publishes and accepts legacy types under Wayland, they see no reason to change any Eclipse code.

This is the main reason that this issue needs to be handled by KDE being more backward compatible: older applications have either no motivation to adapt, or no ability to update (maybe because the software is no longer being developed).

(In reply to Jernej from comment #17)
> kde neon 
> eclipse: 2023-06 (4.28.0)
> gtk: 3.24.33-1ubuntu2
> eclipse relevant conf:
> org.eclipse.swt.internal.gtk.version=3.24.33
> 

comment #10 :
> ...Neon jammy, Eclipse seems to be running with the system's 3.24.34

KDE Neon is based on Ubuntu LTS 22.04 -> jammy
As per:https://packages.ubuntu.com/search?keywords=gtk
the latest available gtk is 3.24.33-1ubuntu1
22.10 (kinetic) has 3.24.34

as per comment #14 , the fix is upstream gtk 3.24.34 , and *not* present in KDE Neon or Ubuntu LTS.


sorry for the confusion. 

-----------

to other user looking in to this, there seems not to be a back port of the latest gtk 3.24.38  to KDE Neon or Ubuntu LTS.
Need move to K/Ubuntu 22.10 or newer....

(In reply to Jernej from comment #20)
> as per comment #14 , the fix is upstream gtk 3.24.34 , and *not* present in
> KDE Neon or Ubuntu LTS.

Thanks for the clarification, but can you please address the fact that I can still repetitive the issue with GTK 3.24.37 (see comment #18)?

Please don't re-open closed bug reports. If you believe you're experiencing the same issue, it's always best to submit a new bug report, because there's a good chance that it's actually a different issue and only *looks* like an old one.

Ok sorry bad my mistake I have opened the issue here instead:
https://bugs.kde.org/show_bug.cgi?id=476522
But my issue also includes the konsole app....

This Issue is now reloved with https://github.com/eclipse-platform/eclipse.platform.swt/pull/863
works with gtk 3.24.33