Bug 512280

> in the clipboard entry should be just a link to the source file
I'm afraid this isn't feasible. Sometimes there is no source file, and sometimes apps only accept image data rather than a file path, or sometimes they treat those data sources differently.

The reason for the larger file is because we have to convert it to png to advertise a proper set of file formats to apps that are picky about which file formats they expect.

If the problem that led to this investigation is really just bad performance, then please just report that instead of proposing solutions. :) 

Would you like this bug report to be about the performance problem?

Your answer looks like speaking about the case when copying an image from image processors and not image viewers.

Please review a little bit deeper the subject, because I am just a user, and not a bug-hunter, nor I am knowing how these apps are working in the background, or what they want or need to achieve.

I turned to plasma 6 in august this year from plasma 5.27.11, using kde from its version 3, and on daily basis from kde 4 from 2011 for almost 15 years. Never, ever encountered such problems, never "observed" that there is klipper working in the background. It was a real help. Now it stays in my way, because of its crappy way to work with images. In the last 10 years (passed thru kde 4 to plasma 5 and now 6) I have exactly the same workflows, using in production on daily basis the same apps (dolphin, gwenview, libreoffice, gimp, inkscape and firefox).

I am not trying to give solutions, just pointing facts, thru which I am trying to help You, who I suppose know better the app, and pass forward to developers the findings, to discover where the bug lies in fact. There are multiple questions related, and is beyond my capacity to discern the source of the problem. I am describing You my previous experience with the same apps and today's one too, and my findings, for helping You to make a correct decision and the app better... usable in fact, because now it is not.

For me now klipper itself because of it's way of image handling, in its actual estate IS THE BIG BUG OF PLASMA 6. (a consequence of this and the related bugs too: https://bugs.kde.org/show_bug.cgi?id=490952 and https://bugs.kde.org/show_bug.cgi?id=502274)

> > in the clipboard entry should be just a link to the source file
> I'm afraid this isn't feasible. Sometimes there is no source file, and
> sometimes apps only accept image data rather than a file path, or sometimes
> they treat those data sources differently.

This might be true for copies made generally from other apps like image processors, office suits etc., not from image viewers (or file managers). From them it is not true! In plasma 5 and plasma 6 too, when copying an image from gwenview, it copies the path to the file. In plasma 5 it does not generates any additional files, but in plasma 6 it does. I suppose that this creation of an additional file is the cause of all problems. But it is beyond my knowledge to see if this conclusion is correct or not. It is the developers capability to check this.

These are my arguments:
Arg. 1. Gwenview is just a VIEWER. Not an image processor. COPY by Ctrl+C means THE ORIGINAL FILE MULTIPLIED and NOT a newly generated image.
Arg. 2. Test Yourself - I. Open image from dolphin in gwenview. – II. Copy that image (Ctrl + C) in gwenview. – III. Close gwenview. – IV. Copy a simple text or anything else from anywhere and check in the clipboard manager that the text is the first, the active entry and the image is the second. – V. In dolphin rename or delete the original file of the previously opened image. – VI. In clipboard manager chose the previously copied image (now the second entry) to be the active, first entry. – VII. Paste it into dolphin – VIII. RESULT: file does not exist.

IX. CONCLUSION: KLIPPER IN FACT COPIES AN USES THE PATH (it should be like so. This is the correct behaviour).

X. QUESTION (THE BUG): Then why it generates that file? THIS IS THE BIG BUG (from my point of view). Because normally it shouldn't, process which creates only problems – I consider.

And I could stop here, because if You confirm that this is the bug, the rest is not relevant.

If your statement would have been true, than this generated image should have been used when pasting. Also, when copying images from anywhere, like dolphin file manager or nomacs image viewer (apps from which copying images works as it should be, without generating anything), also a new image should have been generated in klipper data folder. But this do not happens. Also copying any type of files, they would have been at least copied in klipper's data folder, for the case if the original files would be deleted, modified or etc. This would be a nice feature, maybe, but for now klipper does not work so.

Let assume, that klipper works the way You consider it does. Then:

BUG 1 – why it generates the file if not using it to anything?

BUG 2 – why it does use the path and not the generated image?

It would be very stupid to be like this, because when I want to copy my test.jpg image, it converts it to .png, and if I want to paste it into dolphin for example, it would need to regenerate my original image from that .png, also with all the metadata from my original image, to be the exact copy of the original one. I really wonder, that klipper is doing this, or had to do this, the job of image processing, which is a resource-consuming process.  I consider this also an argument for using just the path, and THE BIG BUG to unnecessarily generate an image when copying from some image viewers. Klipper normally, from my understanding, only has to retain what was in the clipboard and not creating something new.

BUG 3 – why it does not generate a new image in klipper's data folder when copying image from dolphin file manager or nomacs image viewer?

BUG 4 – why this happens only when copying ONE SINGLE image and NOT if multiple ones are copied?

BUG 5 – why grows and stays much higher the RAM usage of gwenview or qimgv during an after making this copy (in case of bigger images even fulfilling my laptop's RAM (16 GB)?

BUG 6 – why on x11 copying happens during a prolonged hangup - 40 sec for the test.jpg image, 90 sec for test-upscaled.jpg?

BUG 7 – why on x11 the clipboard entry most of the time from test.jpg and always from upscailed one is an unusable clipboard entry?

BUG 8 – why on wayland copying happens during a hangup – 7 sec for the test.jpg, 2 sec for the upscailed image?

BUG 9 – why on wayland copying from test-upscailed.jpg instead of the .png file, which should have been generated in the data folder there is only an empty file?

BUG 10 – why on wayland, when copying an image (for example test.jpg) from qwenview, when closing the app, if meanwhile there was no other copying made from other apps, so the last copy is made from gwenview, a next entry is generated in clipboard for the same image. In klipper's data folder the first entry is like described in the first post, with two text files pointing to the source file and a third .png image, the second entry generated at the closing of gwenview contains only the two text files.

So it is up to You to find out which part is THE BUG and belongs to this report and put the report in which category it belongs to,
AND/OR
if You consider, that I should make new report(s) for separated part(s), please do it pointing me for which one(s).

Thank You for Your collaboration and patience!

Bug reports need to be describing a single, discrete, actionable bug. In this case there is there no bug, and now there's a long essay about why everything is wrong. The ticket is no longer actionable, so I'm closing it.

In the future, if you would like to report a specific, actionable bug, please feel free to do so. Reading through https://community.kde.org/Get_Involved/Issue_Reporting may be helpful.

If you feel passionately that the current technical implementation is wrong, the way to go about expressing that is in the form of a patch to correct it.