SUMMARY Even if the "Ignore images" option is enabled, copying an image to the clipboard creates a new entry in the Clipboard applet (but without a preview). SOFTWARE/OS VERSIONS Operating System: KDE neon 5.24 KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 Graphics Platform: X11
Created attachment 147964 [details] Entry with the copied image, but without preview
Where are you copying from?
(In reply to David Edmundson from comment #2) > Where are you copying from? Take a screenshot with Spectacle and click "Copy to Clipboard" or open the image with Kolourpaint and copy it to clipboard.
IIRC spectacle always ignores the "ignore images" setting, since otherwise its copy to clipboard" setting would be quite broken, and we got bug reports about that. I don't really get the point of this "ignore images" setting in the first place and have long supported removing it.
"Ignore images" is an option of the Clipboard applet and I don't understand what Spectacle has to do with it. Does it have to take into account the settings of the Clipboard applet? In my understanding, enabling the "Ignore images" option means that the Clipboard applet will only remember non-image data, while the clipboard itself can still contain any type of data (including images) without restriction.
>In my understanding, enabling the "Ignore images" option means that the Clipboard applet will only remember non-image data, while the clipboard itself can still contain any type of data (including images) without restriction. That's absolutely spot on. However, because spectacle had a mode to take a picture copy to the clipboard and exit it was decided somewhere that klipper should special case it and deliberately ignore the setting. The UI is misleading and confusing, but it is working as intended.
>I don't really get the point of this "ignore images" setting in the first place and have long supported removing it. Most of the time klipper is pointless. It's only useful if the app closes. For text, copying is relatively fast so it's worth it. For images, that's not the case. We're using up a lot of memory and a lot of overhead for something the user probably doesn't want.
Ah, now I figured it out. Yes, this only happens if I use "Copy to Clipboard" in the Spectacle, there is no such problem with Kolourpaint. Surprisingly, but in Ubuntu, using the default GNOME screenshot app, I can take a screenshot, copy it to the clipboard, close the app, open the drawing app, and paste the image from the clipboard. And it works! Maybe we should implement Freedesktop's ClipboardManager specification (https://freedesktop.org/wiki/ClipboardManager/) for this? Sorry if this is a stupid assumption, I'm not qualified in this field.
Maybe. Qt has some code handling save_targets from the client side on exit if a clipboardmanager exists. We do get in that path if xclipboard is running. So we would just need the klipper side. I'm unsure how feasible implementation is without duplicating half of qxclipboard. We also need to think about how a wayland equivalent would work. We don't want x11 only features at this point.
OK, so this behaves as intended, within the current technical and design constraints. Let's get a new bug report to request porting to https://freedesktop.org/wiki/ClipboardManager/, if that's something that we feel might make sense.