Bug 500566

Summary:	Copying screenshot with Copy button results in transparency loss
Product:	[Applications] Spectacle	Reporter:	Ilya Fedin <fedin-ilja2010>
Component:	General	Assignee:	Noah Davis <noahadvs>
Status:	CONFIRMED ---
Severity:	normal	CC:	kde, madness742, nate
Priority:	NOR
Version First Reported In:	6.3.0
Target Milestone:	---
Platform:	NixOS
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Ilya Fedin 2025-02-22 08:33:31 UTC

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

Comment 1 Nate Graham 2025-02-24 15:35:36 UTC

Can reproduce this.

Comment 2 Noah Davis 2025-04-24 08:38:16 UTC

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.

Comment 3 Noah Davis 2025-04-24 08:45:19 UTC

Krita also has this issue, but GIMP does not. It may be a Qt bug.

Comment 4 Ilya Fedin 2025-04-24 09:00:02 UTC

Is this NEEDSINFO for me? What info should I provide?

Comment 5 Noah Davis 2025-04-24 10:57:41 UTC

(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.

Comment 6 Ilya Fedin 2025-04-24 11:08:04 UTC

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.

Comment 7 Ilya Fedin 2025-04-24 18:07:48 UTC

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...

Comment 8 madness742 2025-06-19 13:30:09 UTC

I'm not sure if this is present on older version, but with Spectacle 6.4.0 you can click twice on the `Copy` button to retain transparency.

First copy will have no file name, with no transparency. This will also prevent you from pasting in certain applications.
Second copy will include a file name, with transparency working.