https://bugs.kde.org/show_bug.cgi?id=230895
--- Comment #10 from Friedrich W. H. Kossebau <[email protected]> --- Small update: Since 0.26.23 (released Aug 8th 2025) there is a change which does not yet fix the bug, but might serve more of the real world use cases like the one reported in the comment 2: on a paste (or drop) the clipboard/drag content will be first checked if there is a plain text variant, if so, if it can be, depending on cursor focus, decoded using current byte value type or current 8-bit charset (supporting "\" escaping for non-printable bytes) and in that case then use bytes from the decoding, otherwise fall back to using as before raw data, either of some explicit application/octet-stream variant or the first available data variant. More, when dropping data to create some new byte array (on empty pane or next to tabs), again there will be a check for plain text and if it can be, with higher priority be decoded as hex values, or otherwise be decoded as (escaped) iso-8869-1 chars, only then again as before taking as raw data. So one can e.g. start Okteta, here in the page select the example data of the comment 2, drag and drop onto the empty Okteta pane ,and get a new byte array, with the bytes matching the hex data there and the chars displaying respectively the <script language="javascript">funct. Allowing the user to chose what to use is still to-do, for now the above heuristic is hard-coded, so leaving the bug open. -- You are receiving this mail because: You are watching all bug changes.
