SUMMARY ... moved, containing one less file than the previous one. STEPS TO REPRODUCE 1. "Cut" more than one file (2) from somewhere -> New entry in clipboard containing these two files is created : correct 2. Paste these (2) files somewhere -> In clipboard there is now the original entry, with two files and a new one containing one less file : why? (3.) Cuting and pasting X files creates X clipboard entries with 1,2,3, ... up to X items. Is this a bug or a feature? Also this report might belong somewhere else, but I didn't know where else should I put it. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.61 Qt Version: 5.13.0
I couldn't find a component for the clipboard plasmoid, would "system tray" include it?
The setting the clipboard is somewhat deliberate, so that if a move gets cancelled and you paste again you have what remains not what are now dead links. But the fact that klipper shows this is rather silly.
It's not just about cancelling, it's about cut / paste / paste. Because the first paste updates the clipboard with new URLs, the second paste can work. But the bug report says the cut-of-N-files gets split up into N jobs which all update the clipboard, that sounds like a bug. (in addition I agree that showing this in klipper is useless, but how can klipper detect this? I guess we don't want to just hide all URLs from it?)
*** Bug 433928 has been marked as a duplicate of this bug. ***
(In reply to David Faure from comment #3) > It's not just about cancelling, it's about cut / paste / paste. > Because the first paste updates the clipboard with new URLs, the second > paste can work. > > But the bug report says the cut-of-N-files gets split up into N jobs which > all update the clipboard, that sounds like a bug. > > (in addition I agree that showing this in klipper is useless, but how can > klipper detect this? I guess we don't want to just hide all URLs from it?) Actually, hiding all URLs is something I have been wanting for some time, at least as an option: it is useless to me to be able to select files in the clipboard history, I only want to see text there. But that's another story. One way to avoid the current situation would be to delete the last entry with files and then replace it with the new one. Would a comparison between the new entry and the old ones be too compute-intense to be feasible? This bug is *really* annoying as it basically deletes the whole clipboard history.