SUMMARY When clicking the "Copy" button and pasting the screenshot into other application with Ctrl+V, the resulting screenshot has transparency regions filled with black. This doesn't happen if doing Drag'n'Drop. STEPS TO REPRODUCE 1. Click the Copy buton 2. Paste into other application OBSERVED RESULT Transparency turns black EXPECTED RESULT Transparency is... transparent SOFTWARE/OS VERSIONS Operating System: NixOS 25.05 KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.13.2-cachyos (64-bit) Graphics Platform: Wayland
Can reproduce this.
It seems like there's nothing I can actually do about this in Spectacle's code. Qt's existing clipboard API should be able to handle transparent images. It could be a Qt or Klipper bug. Not sure if KWin has any impact on how the clipboard handles images on Wayland. Is this a recent bug? I feel like I remember it being possible to paste transparency, but I'm not actually sure.
Krita also has this issue, but GIMP does not. It may be a Qt bug.
Is this NEEDSINFO for me? What info should I provide?
(In reply to Ilya Fedin from comment #4) > Is this NEEDSINFO for me? What info should I provide? Did pasting transparency work at any point in the past, including from other KDE apps? My memory about this is not so good.
I don't remember that it worked from spectacle on Wayland. I believe pasting transparent images from other apps worked although not sure. FWIW, a quick look at Spectacle code reveals that it uses KSystemClipboard instead of QClipboard which means it uses a clipboard implementation from kguiaddons (which uses Wayland directly) instead of the Qt one so this couldn't be a Qt bug.
So I finally got around to check other apps: both Gwenview and nomacs lose transparency while firefox didn't. I used a rtotae trick with Gwenview though to avoid it setting a URI to the file in the clipboard. In nomacs, I used the "Copy buffer" item. Firefox's "Copy image" item doesn't set the URI, too. I also re-checked KSystemClipboard code from PC, it does use QClipboard when the window is in focus: https://invent.kde.org/frameworks/kguiaddons/-/blob/master/src/systemclipboard/waylandclipboard.cpp#L644 Starting spectacle, gewnview and nomacs with QT_QPA_PLATFORM=xcb doesn't reproduce the bug. So, yeah, it looks like a Qt bug after all...