hoffmannrobert added a comment.
Some facts: - The clipboard in KDE is a QClipboard instance. - Klipper is a frontend to the clipboard with a history. It exchanges data with the QClipboard instance. - QClipboard provides the facility of setting mime types with data it stores. All data it stores (QMimeData) has a mime type associated. - There is no such thing like a hint in QClipboard. There is only the mime type every data is associated with. - Keepassx (and others) store their passwords and other data with mime type 'text/plain' in the clipboard. I've tried using a different mime type 'text/confidential' in Keepassx and Klipper. Results are: - Selection only works with 'text/plain'. Storing a string with mime type 'text/confidential' (converted to a QByteArray and packed into a QMimeData object) in the clipboard with mode 'QClipboard::**Selection**' results in the error 'QClipboard: Cannot transfer data, no data available'. - Storing such a 'text/confidential' string in the clipboard with mode 'QClipboard::**Clipboard**' works, and Klipper could handle it by not storing it in its history. But unfortunately the clipboard contents are of no use to any application. They check the clipboard with QMimeData::hasText(), which only returns true if there is data with a 'text/plain' mime type and retrieve data from clipboard by calling QClipboard::text(), which only returns 'text/plain' typed data. So telling Klipper to not save something in the clipboard to its history by setting a different mime type doesn't work. If only the QClipboard instance can be used to transfer this not-save-to-history-information to Klipper, the information would have to be contained in the data itself, like some tag in front: 'NOT_FOR_KLIPPER_HISTORY: secret_password'. But then, Klipper must remove the tag from the clipboard content before it's pasted somewhere. If there is no Klipper, the tag must not be used. Seems not feasible. Other options would be to extend QClipboard or QMimeData. Hm, don't think so. So, for an easy but maybe not perfect solution, I changed the history removal patch, so the options RemoveTopHistoryItemOnClear and PreventEmptyClipboard are mutually exclusive now and set RemoveTopHistoryItemOnClear default to false. This way, users can decide by themselves, if they want this functionality and larger organisations can preconfigure these options as needed. REPOSITORY R120 Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D12373 To: hoffmannrobert Cc: graesslin, broulik, davidedmundson, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
