Everything KDE from git master with Qt 6.6.2 on top of Fedora KDE 39. STEPS TO REPRODUCE 1. Begin with Spectacle at its default settings 2. Configure > Image Saving > change default save format to JPEG 3. Quit and re-launch spectacle just to be sure 4. Launch Spectacle 5. Click "Copy" button in the toolbar 6. DO NOT close the main window. With the main window still open, focus a text field that accepts image pastes, such as the comments field of Gitlab merge requests 7. Hit Ctrl+V OBSERVED RESULT Nothing happens EXPECTED RESULT The image is pasted ADDITIONAL INFORMATION If you close Spectacle's main window and then Ctrl+V, the image pastes just fine. This issue does not affect PNG screenshots, only JPEG in my testing. This is the only setting you have to change from the default values to see the bug. I use JPEG as my default save format to reduce my bandwidth when uploading and also reduce other people's bandwidth when downloading my screenshots, since I have a 4K screen and 4k png screenshots can be quite large.
I can reproduce this in Firefox, Chromium and GNOME Web (Epiphany), but not Falkon, Krita, GIMP, KolourPaint or GNOME Draw. GNOME Web is very annoying to test since you can only paste by right clicking and you must authorize a clipboard access request every single time you use it. I think this may be some kind of portal or platform integration issue rather than a Spectacle issue. Might be something that involves permissions since Firefox, Chromium and GNOME Web require permission to access the clipboard while Falkon does not. In order to avoid uploading lots of junk to invent.kde.org, let's use https://new.express.adobe.com/new?width=1920&height=1080 or some other online image/document service as our test website.
Seems like version was accidentally set to 23.04
*** Bug 485705 has been marked as a duplicate of this bug. ***
*** Bug 486658 has been marked as a duplicate of this bug. ***
Possible regression? Can't reproduce with: KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 The format issue is really interesting, the clipboard really shouldn't be affected by whether the file is even saved or not, and it doesn't look like that the image format in the clipboard is affected by the format chosen for files. There's an interesting transformation though when Klipper takes over. Checked: - `wl-paste > testA.png` - Exit Spectacle - `wl-paste > testB.png` And while the two files look identical as pictures, the sizes and file contents are quite different. Looking with `qdbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole` at the clipboard, the only obvious difference is the `x-kde-force-image-copy` mime type getting replaced with `application/x-kde-onlyReplaceEmpty`. Nothing I'm doing is breaking copying from Spectacle on the "old" system I'm using. Worst I get is Klipper sometimes not feeling like picking up new content, setting clipboard back to the previous content after Spectacle exits.
*** Bug 490955 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/graphics/spectacle/-/merge_requests/388
*** Bug 491672 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/graphics/spectacle/-/merge_requests/391
*** Bug 491882 has been marked as a duplicate of this bug. ***
Git commit 83c9a81f3797140740ef9f31e2e6d4e1174115be by Noah Davis. Committed on 23/08/2024 at 20:32. Pushed by ndavis into branch 'master'. Go back to copying images with setImageData A previous change was made based on a wrong assumption that you could only copy one format of image data and that the program doing the copying decides the format that gets pasted. The truth is that the app doing the copying gets to decide which formats are sent to the clipboard and can send multiple types of data, but not which format gets pasted. Only the app receiving the paste gets to decide which format gets pasted. If it doesn't support the copied format, nothing will be pasted. Because of this, images should be copied as uncompressed images. If you want to paste a JPEG into Firefox/Chromium/Electron apps directly, you can't really do that. You have to save a JPEG file and then copy the file as a file URL. I'd like to do that instead so that the copied image can always be compressed in the preferred format, but Flatpak apps currently can't use /tmp without the user adding explicit permission specifically for /tmp. Another issue with trying to copy images directly in the preferred format is that lossy compressed formats like JPEG will be decompressed when Spectacle closes, expanding 2-8x their compressed size. This is likely an issue with Klipper (probably HistoryImageItem) and maybe KSystemClipboard. Related: bug 465781, bug 465972 M +26 -20 src/ExportManager.cpp https://invent.kde.org/graphics/spectacle/-/commit/83c9a81f3797140740ef9f31e2e6d4e1174115be
Git commit 92a59d38ddf1c620a9c318d3f109f202c12c76d4 by Noah Davis. Committed on 23/08/2024 at 21:07. Pushed by ndavis into branch 'release/24.08'. Go back to copying images with setImageData A previous change was made based on a wrong assumption that you could only copy one format of image data and that the program doing the copying decides the format that gets pasted. The truth is that the app doing the copying gets to decide which formats are sent to the clipboard and can send multiple types of data, but not which format gets pasted. Only the app receiving the paste gets to decide which format gets pasted. If it doesn't support the copied format, nothing will be pasted. Because of this, images should be copied as uncompressed images. If you want to paste a JPEG into Firefox/Chromium/Electron apps directly, you can't really do that. You have to save a JPEG file and then copy the file as a file URL. I'd like to do that instead so that the copied image can always be compressed in the preferred format, but Flatpak apps currently can't use /tmp without the user adding explicit permission specifically for /tmp. Another issue with trying to copy images directly in the preferred format is that lossy compressed formats like JPEG will be decompressed when Spectacle closes, expanding 2-8x their compressed size. This is likely an issue with Klipper (probably HistoryImageItem) and maybe KSystemClipboard. Related: bug 465781, bug 465972 (cherry picked from commit 83c9a81f3797140740ef9f31e2e6d4e1174115be) Co-authored-by: Noah Davis <noahadvs@gmail.com> M +26 -20 src/ExportManager.cpp https://invent.kde.org/graphics/spectacle/-/commit/92a59d38ddf1c620a9c318d3f109f202c12c76d4