https://bugs.kde.org/show_bug.cgi?id=511672
--- Comment #8 from erfan <[email protected]> --- On the Rosa forum, before posting the bug report I was directed to this Firefox&Nimbus related bug, but from my point of view, this is not the same. That might be the same with the secondary and third problems mentioned here. I will try to justify it why. In order to report secondary and third problems bug, investigating what is Libreoffice, Firefox, Gimp and Inkscape relation with Klipper, I concluded, that the bug which is related to Gwenview or Qimgv might not be the same. On my Rosa installation, on the Lenovo laptop, Libreoffice, Firefox, Gimp and Inkscape, when Only when explicitly copied option is selected, all has a hang up, when trying to copy a bigger image. Libreoffice, Firefox and Gimp after a hangup in the clipboard there is just an empty line on which if QRcode can be generated, it writes out a -1x-1. Sometimes this text appears in clipboard history too. When Never save in history is choosed, then Libreoffice, Firefox and Gimp works correctly, Inkscape not. In both cases Klipper saves from Inkscape not an image but a huge textfile, which proves to be in fact an .svg, because if I succeed (because it finally crashed – or the texteditor, or plasmashell runs out of memory) to copy the text into the texteditor (kwrite) and save it as .svg, imageviewers opens it correctly. Searching on web some infos regarding this, pointed me to check what is inside ~/.local/share/klipper/data/. It doesn’t come to my mind before, to check the records here, but good point regarding the Gwenview and Qimgv problems too. What I discovered is, that whenever Klipper succeeds to create a correct record from Gwenview or Qimgv from a picture, it creates a new image inside the record’s own folder and not just the files indicating the source of the image. If the image can be created, than it will not be the a copy of the original one, but it will be a completely different one (in my case the 3.1MB sized test.jpg image was 19.1MB big PNG image). On Wayland if it cannot start to create this new image for test-upscaled.jpg, it drops quickly an empty file instead of it, and the clipboard entry seems to work correctly. That is why the hang up is way more shorter for more bigger images. The images from Libreoffice, Firefox, Gimp and Inkscape, including screenshots mentioned in the Nimbus related bug are in a temporary, ephemeral estate, because they are embeded infact into an .odt, .xcf, .svg file (I don’t know how Firefox handles images) so clipboard takes them ot from here an tries to save them for later use, creating a personal copy of them. (I do not know why it does not take directly the picture out from .odt because if I chose to edit the image with an external editor from within Libreoffice I can do it without problem) So, the creation of the new file generates the hang up. That might be the same problem in all cases. Copying large file on: X11 New image is not generated in Klipper’s data folder over a certain image size, resulting a prolonged hangup or finally crash of the source app and unusable record is created Wayland New image is not generated in Klipper’s data folder over a certain size, but shortly, in 0-2 seconds the system realizes it cannot create it and usable record is generated. BUT those images shown in imageviewers like Gwenview and Qimgv are existing images, with which Gwenview and Qimgv works directly, without embedding them in other formats. They are just viewers. Even if, for example, when cropping an image in Gwenview: after choosing the cropped area and applying it, Gwenview attentions me that changes where made and what I want to do – save it as a new file or replace the original, or save all changes (for all files). BUT if in this estate, before saving, but already after applied cropping, I choose to copy the image, it wont copy the cropped one, but the original one. I concluded that Gwenview itself do not creates a new temporary file on which it works, so it is completely unnecessary that Klipper to create a completely new file when copying, instead of just pointing to the source file. The hangup is one problem. The creation of new images in Klipper’s data folder in vain when copying from Gwenview or Qimgv (while the text records belonging to the clipboard entry in Klipper’s data folder pointing to the original source file) is a second one. And this second one is what bothers me most at this moment. If it would work correctly, without generating that inutile image, I could manage to use Klipper in Never save in history mode, so that images from other apps not being saved, only those coming from sort of built-in, tightly related apps to plasma like dolphin or Gwenview. I should let this bug report as a duplicate of the Nimbus problem and the second discovery, which directly affects me to be a new one? I attach Klipper data tested on tumbleweed, to have the X11 and Wayland behavior on the latest plasma 6.5.2 tested?. Three times klipper on X11 acted differently with the upscaled image. https://mega.nz/file/ZAIxEbJL#Y4DbONY2_8b27RmWscQK0bz6q8H84OkV7J-w66fzlBg The screenshot is from the first X11 test. There was a first copy from Dolphin, second one from Gwenview with test.jpg, repeating the same with the upscaled image. On the wayThenX11 klipper data, I copied first in Wayland then recopied on X11. X11 recognized after hang the test.jpg clipboard record, but not the upscaled one. It created an errored one. In the data folders the ones with an empty file or a small thumbnail image are from the upscaled image. -- You are receiving this mail because: You are watching all bug changes.
