https://bugs.kde.org/show_bug.cgi?id=511672
--- Comment #5 from erfan <[email protected]> --- Main problem of this bug report: The hang-up problem I observed it only with Gwenview in relation with the Clipboard Manager, no matter what option is choosen. If the Clipboard Manager is completely disabled, there is no problem. UPDATE: testing MxLinux 25 with plasma 6.3.6, on the iso qimgv is the default viewer instead of gwenview. It acts exactly in the same way as gwenview. So gwenview is not the only app acting alike. Tested qimgv on the Opensuse Tumbleweed too, it confirms that to me. So for the moment only Nomacs works with Clipboard Manager as intended. A secondary problem regards Non-text selection’s options. It is not the subject of this hang-up bug report, but I think it has to be addressed too, if it has not been reported already: No matter which option is chosen in 'Non-text selection - Only when explicitly copied / Never save in history', copying from Dolphin, Gwenview (with hang up) or Nomacs, the images are copied with thumbnails into the Clipboard Manager. Maybe I do not understand correctly, but Never save in history (with that explaining info under the option) means for me, that in this case images should NOT be copied into the Clipboard Manager. But, in relation with Libreoffice, Clipboard Manager works somehow more correctly, because if 'Never save in history' is chosen, than image is not saved. Problem occurs when 'Only when explicitly copied' is chosen, image is somehow copied, but it generates seemingly an empty line in Clipboard Manager, without a thumbnail or text info about the content of the record, so impossible to find in clipboard history if you have multiple images copied one after the other. From this empty record the image can be copied back to a Libreoffice document, but not into gimp for example, which gives the error of not having any data to copy. Third problem is: Seems like Clipboard Manager do not copies any image from Gimp, Inkscape, KolourPaint for example, no mater what option I choose. So, the second and third problems might be considered also as bugs, including the libreoffice-regarding one too. So, from my perspective Plasma 6 Clipboard Manager is a completely unusable piece of software. On X11 I succeeded to partially replace it, but on wayland I haven’t found a replacement for it. Getting back to the hang-up bug and that you cannot reproduce it, it might be because different software and hardware combination, even if the whole system is the same, will react differently. But on my hardware on each distro plasma acts almost the same, just the timing is different, depending on distro and hardware used. All hardware works correctly with plasma 5 on X11, no hang up, even with very large images. Maybe try on X11 too, because there is more evident the problem, with more drastic results. I can reproduce this on two laptops. One is a Dell Vostro 15 3530 with an 13th Gen Intel® Core™ i7-1355U, 15.3 usable RAM and a LENOVO IdeaPad Slim 5 15ARP10, AMD Ryzen 7 7735HS with 12.7 GB usable RAM, beginning from the installation iso of Rosa which runs plasma 6.3.1 on X11, then on 6.4.3 and 6.4.5 installations on X11 and Wayland too, on other kde distros running plasma 6, until the latest KDE Neon iso with plasma 6.5.1 (neon-user-20251106-0745.iso) and Opensuse Thumbleweed with 6.5.2 (openSUSE-Tumbleweed-KDE-Live-x86_64-Snapshot20251106-Media.iso), both on X11 and wayland. To test with the latest plasma 6.5.2 I made my tests on the Opensuse Tumbleweed live iso. For testing purposes I upscaled the test image and made the test on X11 too. There is more accentuated the problem, because for bigger images clipboard entry is always an empty record, or if sufficiently big, in the end gwenview will crash. What I observed, that during copying (CTRL+C) into clipboard, on X11 the processor works a lot, sometimes completely at 100% (all threads together), gwenview memory usage gets bigger and bigger, starting from around 750MB for the upscaled image until 3.7GB, and when the empty record is created remains at 2.3GB, not returning to its starting usage, as when Clipboard thumbnail is created normally. If the image is sufficiently big, it runs out of memory and gwenview will crash. I don’t think this is normal what does gwenview or klipper generates in gwenview from a 10-20-30 MB sized images, resulting in several GB memory usage for a simple copy (CTRL+C). When klipper is completely disabled, there is no processor or memory usage increase for gwenview (UPDATE: or qimgv) when copying then pasting an image, and everything work OK. ----------------------------------- Hang-up results on DELL, with Opensuse Tumbleweed live iso with plasma 6.5.2. X11 test.jpg – sometime 43 sec. hang resulting an empty record in clipboard, or sometime 15 sec. hang with normal record in clipboard. test-upscaled.jpg – 1 min. 40 sec. hang – always an empty record in clipboard If the clipboard is not empty, trying to click on it during the hangup, at the end of it might result in a longtime, maybe complete freeze of panel. I had no patience to wait plus than 5 minutes to see if it recovers or not. Wayland test.jpg – 5 sec. hang – normal record in clipboard test-upscaled.jpg – no hang – normal record in clipboard Curious, why on Wayland it hangs for the smaller image and not for the bigger one. It happens the same on all tests.. X11 at least acts more logically. ----------------------------------- Hang-up results on Lenovo, with Opensuse Tumbleweed live iso with plasma 6.5.2 X11 test.jpg – 28 sec. hang – normal record in clipboard test-upscaled.jpg – 1 min. 45 sec. hang – empty record in clipboard Wayland test.jpg – 7 sec. hang – normal record in clipboard test-upscaled.jpg – 1 sec. hang – normal record in clipboard ----------------------------------- Hang-up results on Lenovo, with Rosa Desctop Fresh 13 intallation with plasma 6.4.5 Wayland test.jpg – 14 sec. hang – normal record in clipboard test-upscaled.jpg – 2 sec. hang – normal record in clipboard The original and upscaled test images and some screenshots I uploaded here: https://mega.nz/folder/AJBRxKqY#3I5lc1KQqtnO9lKhPyxVHA -- You are receiving this mail because: You are watching all bug changes.
