| Summary: | When default screenshot format is JPEG, screenshots copied to the clipboard cannot be pasted until Spectacle quits | ||
|---|---|---|---|
| Product: | [Applications] Spectacle | Reporter: | Nate Graham <nate> |
| Component: | General | Assignee: | Noah Davis <noahadvs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 4wy78uwh, boredsquirrel, dev.bacteriostat, elman, izerpizer, kde, kdedev, mpalys7274, phil.rigby, voidpointertonull+bugskdeorg |
| Priority: | HI | ||
| Version: | git-master | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=491682 | ||
| Latest Commit: | https://invent.kde.org/graphics/spectacle/-/commit/92a59d38ddf1c620a9c318d3f109f202c12c76d4 | Version Fixed In: | 24.08.1 |
| Sentry Crash Report: | |||
|
Description
Nate Graham
2024-04-05 16:33:31 UTC
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. *** *** 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 |