https://bugs.kde.org/show_bug.cgi?id=476522
--- Comment #4 from Oded Arbel <o...@geek.co.il> --- 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. -- You are receiving this mail because: You are watching all bug changes.
