Summary: | Klipper puts "application/x-kde-onlyReplaceEmpty" first when it should be near the end of the mimetype list | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | TraceyC <kdedev> |
Component: | general | Assignee: | KIO Bugs <kio-bugs-null> |
Status: | RESOLVED NOT A BUG | ||
Severity: | normal | CC: | kdelibs-bugs, nate, noahadvs |
Priority: | NOR | Keywords: | regression |
Version: | 6.5.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
See Also: |
https://bugs.kde.org/show_bug.cgi?id=491961 https://bugs.kde.org/show_bug.cgi?id=492006 |
||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
TraceyC
2024-08-21 21:20:33 UTC
Relevant stuff is in src/widgets/paste.cpp I've determined that Klipper is not actually at fault. It's actually a KIO paste dialog problem that "application/x-kde-onlyReplaceEmpty" comes first. Klipper puts it last in the format list like it should. In bug 491961 I assumed that the paste dialog formats followed the order of the formats list since the image formats were shown in that order, but I suppose it's slightly different. For posterity, the real bug is bug 492006. After a bit more testing, it's still technically an issue for KIO, but the actual source of the format ordering issue is probably something more internal to Qt. It seems that first Klipper uses QMimeData::setImageData, which only sets "application/x-qt-image". After that, Klipper sets "application/x-kde-onlyReplaceEmpty". Slightly later it appends all the other image formats. This is why "application/x-kde-onlyReplaceEmpty" shows up before PNG. It seems like you can't assume that hint mimetypes will go after the automatically set image types even if you set them after QMimeData::setImageData. |