https://bugs.kde.org/show_bug.cgi?id=447831
--- Comment #13 from Noah Davis <noaha...@gmail.com> --- (In reply to Roke Julian Lockhart Beedell from comment #12) > (In reply to Noah Davis from comment #11) > Those are very good points, and I'd be glad to wait for this until those > issues you mean are solved. If any are being tracked here, can they be > listed as blockers? (Are those Qt bugs?) The clipboard contents compatibility issue is arguably a Firefox/Chromium/WebKit/Electron issue. Maybe it's fixable in those projects, but it's odd that it has been effectively worked around in KDE and Qt code. Fundamentally, it means we can't assume apps will accept a given image format, regardless of whether the issues are fixed. I'm not exactly sure where the decompression issue comes from. I made a test project (https://invent.kde.org/ndavis/clipboardimageformatwidgets) and tried to find parts of qtbase that might be relevant. I know Qt adds a bunch of extra mimetypes to the clipboard data for compatibility. In qtbase/src/gui/kernel/qinternalmimedata.cpp there is a part where it will try to write a PNG, but that's only if there's no data for the given mimetype. I also checked Klipper and KSystemClipboard and tried patching those (https://invent.kde.org/plasma/plasma-workspace/-/commit/8cff887b146353fbe4f7681061624581775fa820 and https://invent.kde.org/frameworks/kguiaddons/-/commit/ae1535c6d893041e36c0cd0c1128b092f71aa62f). Unfortunately, there was still no way to reliably prevent decompression. Fundamentally, I don't know if the issues can be fixed and I don't know if the decompression issue is just a side effect of behavior that is necessary for compatibility with apps that don't support most writable image formats. -- You are receiving this mail because: You are watching all bug changes.
