BTW: For pasting into Firefox I used https://codepen.io/netsi1964/pen/IoJbg.

(For dropping there is https://codepen.io/esausilva/pen/RKVoQw, but this seems to only work with URLs.)

Works good for all images and destination apps I found. :)
There's only one issue with non image selections (see inline comment).

@rkflx wrote:

However, I just noticed that pasting a cropped NEF will set the correct mimetype (due to my patch), but the pasting itself will fail in the end. Maybe Dolphin can only paste Qt's image formats after all?

I suspect Gwenview only loads the JPG preview embedded in the raw files but the mimetype is identified by the original file.

I don't think we can assume PNG in every case?

It seems application/x-qt-image is always a PNG image. At least I did not see anything other so far.

In D13028#266284, @muhlenpfordt wrote:

It seems application/x-qt-image is always a PNG image. At least I did not see anything other so far.

I'm wrong - it's the format that doc->image() returns.
Using mimeData->setImageData(doc->rawData()) works and copies e.g. a JPG image to application/x-qt-image.
Edit: To be clear - 'works' means the JPG data is copied, but unlike setting a QImage the image is not converted and all other mimetypes are empty.

In D13028#266284, @muhlenpfordt wrote:

@rkflx wrote:

However, I just noticed that pasting a cropped NEF will set the correct mimetype (due to my patch), but the pasting itself will fail in the end. Maybe Dolphin can only paste Qt's image formats after all?

I suspect Gwenview only loads the JPG preview embedded in the raw files but the mimetype is identified by the original file.

But then renaming to JPG should work, however nothing gets pasted in the first place. This also happens for TGA, which should not have a JPG preview embedded. And indeed, after removing doc->image() Dolphin will not even initiate the paste dialog.

I don't think we can assume PNG in every case?

It seems application/x-qt-image is always a PNG image. At least I did not see anything other so far.

In D13028#266285, @muhlenpfordt wrote:

it's the format that doc->image() returns.
Using mimeData->setImageData(doc->rawData()) works and copies e.g. a JPG image to application/x-qt-image.

That's strange, because for me Dolphin (and xclip too) presents a list of multiple different mimetypes, and upon selecting one it will convert the format correctly (cross-checked by examining the pasted file with Okteta).

Maybe we can do something like this:

• If Qt supports our format, directly set the correct format and filename extension.
• If not, don't set the format, and set the extension to PNG (assuming it will always be the first item in the list).
• Possibly extend Dolphin in the future to add the correct extension when changing the format selection.

Works perfect for the common file formats.
For a couple of image formats (e.g. TGA, BMP, PBM, PNG) doc->rawData() returns an empty array (modified or not). If the file was modified this results in Dolphin not saving for image/x-tga, etc. and you have to select another mimetype to create the file. PNG seems to be a special case and works anyway.
I'm not sure if this is a bug or feature of Document?
Any idea how Dolpin selects the preferred mimetype - maybe we could just mark this without setting the data?

Hm, this patch is getting really complicated…

In D13028#266875, @muhlenpfordt wrote:

For a couple of image formats (e.g. TGA, BMP, PBM, PNG) doc->rawData() returns an empty array (modified or not).

Yeah, we only need doc->rawData() for the SVG case, for the rest merely the setData(mimeType, …) part seems important. I don't think there is a way to set a preferred mimetype in KIO/Dolphin yet.

If the file was modified this results in Dolphin not saving for image/x-tga, etc. and you have to select another mimetype to create the file.

Here it gets interesting: I cannot reproduce your claim for BMP, but I can see it for TGA and PBM. I don't think the empty data is the cause, but some X11 clipboard weirdness. The reason is that Qt's and our mimetypes are image/x-tga and image/x-portable-bitmap, while somehow the clipboard announces image/tga and image/pbm, which then leads to failure. You can see this in the combobox, where there is a long description for the former, and the latter only has image/… (relevant code), or by comparing qDebug() << mimeData->formats() and xclip -o -selection clipboard -t TARGETS.

Qt reads the formats from the clipboard here, then KIO tries to read the data here. As the clipboard has image/tga, but we lookup data for image/x-tga, we don't get something useful back.

So far I could not find the place where the other formats get added to the clipboard, so I'm kinda stuck. Probably somewhere after here.

On Wayland only BMP seem to work at all for me, so somehow this is broken too? Or do we need a workaround like this?

Unfortunately more questions than answers at this point…

Anyway, I guess we have two options:

1. Set the proper image data:

QByteArray bArray;
QBuffer buffer(&bArray);
buffer.open(QIODevice::WriteOnly);
doc->image().save(&buffer, QFileInfo(url.fileName()).suffix().toLatin1());

mimeData->setData(mimeType, bArray);

This means actually performing the conversion to the target format by ourselves, while currently this conversion seems to take place only on demand (no idea where, though?).

Also, this is more of a workaround, as normally setImageData(doc->image()) should be enough.

2. Only go with PNG for now:

• Revert setData(mimeType, …).
• Possibly later add a patch to KIO to determine the preferred format from the suggested filename extension (or set PNG if there is none), and then adapt Gwenview accordingly. TGA would still be broken, of course.

I'm leaning towards option #2, as it's less of a hack which would probably bite us later on Wayland. Thoughts?

Any tips for debugging image/tga further, i.e. where is this coming from, and how does mapping from application/x-qt-image to the various formats work?

In D13028#267373, @rkflx wrote:

Any tips for debugging image/tga further, i.e. where is this coming from, and how does mapping from application/x-qt-image to the various formats work?

That function looks related…

…and then we end up in here and over there – might be a bug in Qt, after all (unless some specification says otherwise, e.g. the clipboard should not contain XDG mimetypes on Windows?).

I wonder why in imageWriteMimeFormats() Qt uses QImageWriter::supportedImageFormats() and not QImageWriter::supportedMimeTypes(). Seems like in https://bugreports.qt.io/browse/QTBUG-28177 the concept of mimetypes was introduced, but still in a couple of places the custom file extension "mimetypes" are used (e.g. here).

Eventually this decision will break showing the correct description in KIO, unless there is a way to map from extension back to mimetype.

Note that in Qt 5.12 there will be a mapping for the opposite direction (see https://bugreports.qt.io/browse/QTBUG-49714) (still the wrong direction, and for images only, of course).

In D13028#267373, @rkflx wrote:

If the file was modified this results in Dolphin not saving for image/x-tga, etc. and you have to select another mimetype to create the file.

Here it gets interesting: I cannot reproduce your claim for BMP, but I can see it for TGA and PBM.

Right, for BMP the correct mimetype image/bmp is returned. It's confusing since pasting to Dolphin also fails for bigger images sometimes (BMP/TGA 2812x2370 fails but e.g. scaled to 2400x2022 works).

The reason is that Qt's and our mimetypes are image/x-tga and image/x-portable-bitmap, while somehow the clipboard announces image/tga and image/pbm, which then leads to failure.

I think the image/x-... should not be used if no content is attached to it, only the mimetypes provided by Qt.
Just converting e.g. image/x-tga to image/tga and attaching an empty QByteArray via setData() seems to work but it's not a nice solution... ;)

2. Only go with PNG for now: I'm leaning towards option #2, as it's less of a hack which would probably bite us later on Wayland. Thoughts?

Seems to be the best option for now. With setting the provided filename suffix to .png this should work ok.

Any tips for debugging image/tga further, i.e. where is this coming from, and how does mapping from application/x-qt-image to the various formats work?

It looks like the pasting application (or Qt here) has to provide a callback function which converts the image data on request. If we want to offer additional formats/mimetypes we have to extend this callback by ourself.
It's for Gnome but I think this is the normal X11 clipboard: https://developer.gnome.org/gtk3/stable/gtk3-Clipboards.html

In D13028#267544, @muhlenpfordt wrote:

It's for Gnome but I think this is the normal X11 clipboard: https://developer.gnome.org/gtk3/stable/gtk3-Clipboards.html

Thanks, that gave a nice introduction.

In the meantime, I also found where image/tga comes from (see edits above).

Summary on what we've learned:

• Unsetting the URL for modified images makes sense, as then the clipboard only contains the correct modified raster data.
• KIO should be modified to infer the default mimetype to use from the filename extension (or provide a method to set it explicitly).
• The way Qt works results in the clipboard's TARGETS atom announcing "formats", but not "mimetypes".

In D13028#268021, @muhlenpfordt wrote:

Looks flawless to me and I can't spot any more issues. :)

Thanks for finding the issues in the previous iterations ;)

I think the behaviour is totally comprehensible and it's not worth fiddling with the original image formats.

You mean KIO should not be adapted to react to the passed filename extension, and users should manually switch from PNG to JPG when they are pasting from a JPG? Or was this about setData()?

In D13028#268410, @rkflx wrote:

You mean KIO should not be adapted to react to the passed filename extension, and users should manually switch from PNG to JPG when they are pasting from a JPG?

Sure, if any of the libraries offers a better way to handle this, it will be an improvement but for the current conditions it's a good solution.