Are there someone have the same problem about the system clipboard?
It can not work for gtk applications such as chrome, zotero, except firefox…
However, it works fine in x11-plasma-6.1
I have not encountered a real issue with pasting text copied into the system clipboard, into GTK apps, but - depending on how ancient your GTK app, you might have problems copying from GTK apps to the system clipboard: when you copy something in Linux, the application sending the copy is in charge of specifying what is the format of the data and there are various format specifications that were used - in the past - to say “this is some text” that are now discouraged or outright unsupported. If the sending application is publishing in some really bizzare format - that could be a problem.
Can you please explain more about your situation? What specific use case is not working well for you?
after update plasma to 6.1 and reboot, I can not copy strings from chrome to system clipboard (klipper?), I check many gtk applications, such as chromium, zotero, vscode,and firefox (firefox works well). In fact, gtk applications can copy and paste in save applications. I cannot find any string from this application in the system clipboard. In those applications I can paste from system clipboard.
This is my system info
-`
.o+` ---------------------
`ooo/ OS: Arch Linux x86_64
`+oooo: Host: Code01 Ver2.0 1
`+oooooo: Kernel: 6.9.7-AMD-znver3
-+oooooo+: Uptime: 1 day, 2 hours, 45 mins
`/:-:++oooo+: Packages: 2898 (pacman)
`/++++/+++++++: Shell: fish 3.7.1
`/++++++++++++++: Resolution: 1920x1080
`/+++ooooooooooooo/` DE: Plasma 6.1.2
./ooosssso++osssssso+` WM: kwin
.oossssso-````/ossssss+` Theme: Apu's [Plasma], Breeze [GTK2/3]
-osssssso. :ssssssso. Icons: WhiteSur [Plasma], WhiteSur [GTK2/3]
:osssssss/ osssso+++. Terminal: yakuake
/ossssssss/ +ssssooo/- CPU: AMD Ryzen 7 6800H with Radeon Graphics (16) @ 4.785GHz
`/ossssso+/:- -:/+osssso+- GPU: AMD ATI Radeon 680M
`+sso+:-` `.-/+oso: Memory: 12218MiB / 30819MiB
`++:. `-/+/
Can you try this, please:
- Start a terminal
- Copy something from Chrome (or another app you have trouble with)
- Run the following code:
python -c 'import gi; gi.require_version("Gtk", "3.0"); from gi.repository import Gtk, Gdk; print(*Gtk.Clipboard.get(Gdk.atom_intern("CLIPBOARD", True)).wait_for_targets()[1], sep = "\n")'
(Taken from this StackOverflow post)
- And record it’s output
- Then copy from Firefox (or another non-KDE app that behaves) and run the command again.
- Post both snippets here.
BTW - to get useful system info for putting into this forum, it is best to run kinfo - it gives more information that is relevant to the participants here and is missing from the output you shared - such as which windowing protocol you use and what is the Qt version (it also skips on the vanity ASCII art).
Thank your very much!
python -c 'import gi; gi.require_version("Gtk", "3.0"); from gi.repository import Gtk, Gdk; print(*Gtk.Clipboard.get(Gdk.atom_intern("CLIPBOARD", True)).wait_for_targets()[1], sep = "\n")'
chrome: output is nothing!
firefox: same nothing.
Operating System: Arch Linux
KDE Plasma Version: 6.1.2
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.9.7-AMD-znver3 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 6800H with Radeon Graphics
Memory: 30.1 GiB of RAM
Graphics Processor: AMD Radeon 680M
Manufacturer: MECHREVO
Product Name: Code01 Ver2.0
System Version: 1
Yea, I copy and pasted that as it looks like its supposed to work and is display protocol agnostic - and I didn’t test it properly.
On my Wayland system it also shows up empty and after trying to get it to work for a few minutes, I gave up.
If you are on X11 (I think you mentioned that above), can you try the same exercise with running xclip -o -t TARGETS?
xclip -o -t TARGETS 0 < 19:18:47
TIMESTAMP
TARGETS
SAVE_TARGETS
MULTIPLE
STRING
TEXT
UTF8_STRING
text/plain
text/plain;charset=utf-8
from plasma-x11
That’s for which use case? Chrome or Firefox?
chrome,
this for firefox
TIMESTAMP
TARGETS
MULTIPLE
text/html
text/_moz_htmlcontext
text/_moz_htmlinfo
UTF8_STRING
COMPOUND_TEXT
TEXT
STRING
text/plain;charset=utf-8
text/plain
text/x-moz-url-priv
The formats that I wanted to make sure are there, are there for both: STRING, UTF8_STRING, TEXT, text/plain, and text/plain;charset=utf-8.
I’m trying something with Qt clipboard to see if I can send you a test program that will get more information, but it doesn’t work for me yet. I’ll get back when I have more info.
Thank you, you are so kind.
In fact, the problem may from every application runing under xwayland.
I check chromium with option chromium --enable-features=UseOzonePlatform --ozone-platform=wayland, clipboard works well.
Oh. I thought you were running X11. If you’re running Wayland, that’s a whole other thing. I’ll have more info tomorrow.
hahahaha, Do not think when using X11, there are no other problems…….
Under current situation, the wayland is better.
Can you try to install the wl-clipboard package, then copy something from an X11 application (such as Chrome) that you can’t paste into a KDE application and then run wl-paste -l and post the results here?
wl-paste -l
Nothing is copied
Nothing is copied.
That means there is no synchronization between the X11 clipboard and the Wayland clipboard - the xclip sees the data while the wl-clipboard does not.
The synchronization is the responsibility of kwin I believe - there used to be a standalone helper called xclipboardsync that did this in Plasma 5 but in 6 it was converted to something called “XWayland Selections” and I’m not sure where it is implemented now - its one of those things that you don’t think about until it breaks.
Maybe if a kwin developer can pop their head in, they’d have more information. I do recommend though that you open a ticket about it in bugs.kde.org on kwin and at least someone will be able to help you with more debug steps.
Thanks, I wil try to report a bug no synchronization between the X11 clipboard and the Wayland clipboard
This issue seems to be bug 490577 that has been fixed for Plasma 6.2. I had it happen to me a couple of time but it didn’t reproduce well.