Created attachment 140365 [details] Small RTL copied text is totally hidden on mouse hovering When a small RTL text is copied, then mouse pointer passes over it in Klipper that text becomes totally hidden. See attached video for more info.
Yeah this is semi-intentional. We always position the buttons in the same place so that they don't change positions when list items are added, removed, etc. If we reversed the position for RTL text items, the buttons would jump around and we would get bug reports about that, I guarantee it. People would hate that. People hate UI elements jumping around just as a general thing. When using the whole system in RTL move, the buttons move over to the left side as expected though.
Wouldn't be best if the text is detected as RTL to be pushed to left by the width of those buttons. Or at least give user an option to decrease the number of those buttons, because only remove button is useful, the others like barcode (I don't know who came with this weird function inside Klipper), Edit (editing is always done in target app where item is copied) and Invoke are rarely (or never) used.
No, because then the buttons would jump around depending on the content. This is exactly what we are trying to avoid. I don't disagree that those other buttons are rarely used and not very useful, but please open another bug report about that. :)
(In reply to Nate Graham from comment #3) > No, because then the buttons would jump around depending on the content. > This is exactly what we are trying to avoid. What I meant is to move a little the text which is detected as RTL to left and not the buttons, at least to make the start of the copied text visible to user in order to avoid any accidental deletion or wrong click. See attached image for more info.
Created attachment 140371 [details] Move hidden RTL text to left
Oh I see. Yeah that seems reasonable.
Five years later, this is no longer the case. In LTR system (ie. English), even strings in Arabic (I found this one: لوحة المفاتيح العربية ) are shown from the left. And when I launched plasma in Arabic with LANGUAGE=ar_SA plasmashell --replace both Latin and Arabic entries in Klipper were on the right. So the original bug is gone and I will close this one. If somebody who actually lives in a mixed environment strongly feels that text in Arabic in a LTR locale should be aligned to the right, feel free to reopen or open a new bug. I am sadly a completely LTR person so I cannot judge, either makes sense to me. In that case, we would indeed need to shift the text to the left to evade the buttons. Not sure how much code it would need, but until somebody who actually needs it asks for it, I will close this (of course, if it still affects you, reopen).
(In reply to Tomáš Hnyk from comment #7) > Five years later, this is no longer the case. In LTR system (ie. English), > even strings in Arabic (I found this one: لوحة المفاتيح العربية ) are shown > from the left. And when I launched plasma in Arabic with LANGUAGE=ar_SA > plasmashell --replace both Latin and Arabic entries in Klipper were on the > right. > > So the original bug is gone and I will close this one. If somebody who > actually lives in a mixed environment strongly feels that text in Arabic in > a LTR locale should be aligned to the right, feel free to reopen or open a > new bug. I am sadly a completely LTR person so I cannot judge, either makes > sense to me. > > In that case, we would indeed need to shift the text to the left to evade > the buttons. Not sure how much code it would need, but until somebody who > actually needs it asks for it, I will close this (of course, if it still > affects you, reopen). If we talk about a correct fix it would be: aligning RTL text to right then push those buttons to right, why? because reading Arabic is from right to left, when you have one copied word or two it doesn't matter because all of it will be visible even if aligned to left, but when you have a long copied RTL text you will only see the end of text which is not natural and incorrect and make it difficult to choose the highlighted item. One optimal solution would be to push all those annoying hovering buttons to a vertical small column at right like how CopyQ does it, then show every copied item correctly based on its language: RTL aligned to right and LTR aligned to left.
So in LTR environment, with mixed it would be: latin text BUTTONS | لوحة المفاتيح العربية BUTTONS | (does that string start with لو ?) In RTL environment, it would be BUTTONS لوحة المفاتيح العربية| BUTTONS latin text | Do I get it right?
(In reply to Tomáš Hnyk from comment #9) > So in LTR environment, with mixed it would be: > > latin text BUTTONS | > لوحة المفاتيح العربية BUTTONS | > > (does that string start with لو ?) > Yes, the starting of the second item in Arabic is 'لو' and ends with 'العربية', in Arabic and other RTL languages like Hebrew you both read and write text from right to left. > In RTL environment, it would be > BUTTONS لوحة المفاتيح العربية| > BUTTONS latin text | > > Do I get it right? I'm not sure how devs are deciding global direction for gui components.
Ok, I will reopen, but it is possible this is not a bug in Klipper but higher up the stack. Elsewhere in KDE mixing RTL and LTR works? (unrelated, but I always wondered about mixing the two. the one thing I do not understand is that left and arrow keys when inside the arabic switch meanings, so the cursor jumps around in as tring like "ext ح العربية BUTTONS |" pushing right goes from ext to ح and then starts going left to ة and then jumps to BUTTONS. I mean I understand the logic, sort of, but is it really usable in practice?)
(In reply to Tomáš Hnyk from comment #11) > the one thing I do > not understand is that left and arrow keys when inside the arabic switch > meanings, so the cursor jumps around in as tring like "ext ح العربية > BUTTONS |" pushing right goes from ext to ح and then starts going left to > ة and then jumps to BUTTONS. In LTR text the left arrow advances while reading or writing text, the same for RTL text the right arrow is the one advancing inside text, so when you mix both RTL and LTR the direction of reading/change instantly inside (see attached image1.png). > I mean I understand the logic, sort of, but is > it really usable in practice?) I'm from Morocco and we use different languages: the two official languages: Arabic and Tamazight, plus we study in school French then English and also Spanish (in some northern part of the country), in media/books/articles and also school it's impossible to explain some concepts or new notions or introduce foreign names without using directly foreign languages, especially english which is already the most used language for anything new, so mixing LTR words inside RTL text is normal and sometimes necessary (see attached image2.png from a local written media).
Created attachment 196690 [details] image1.png Example of LTR words inside RTL text.
Created attachment 196691 [details] image2.png
Yeah, I understand what is happening and the need to mix, and even why, I just wonder if I ever could use to something that says and points "left" going "right". But we are off topic here :-).
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/7141
Turns out it was not that difficult, I hope it is correct and that you like the result.
Git commit 9f12c34a85a69b97ced7a3c4cc2981fa66e426e4 by Nate Graham, on behalf of Tomáš Hnyk. Committed on 01/10/2026 at 18:52. Pushed by ngraham into branch 'master'. Klipper: Mix LTR and RTL scripts naturally Arabic text was always aligned to the left in a left-to-right session (and Latin alphabet text to the right in a right-to-left session), which was unnatural. Moreover, the start of such text was obscured by the tool buttons on hover. Each entry is now aligned in the natural direction (i.e. Arabic from the right, Latin alphabet from the left), like lines in Kate, for example. When the tool buttons show, the text is moved next to them and fading is turned off, as there is no text under the buttons. FIXED-IN: 6.9.0 M +21 -3 klipper/declarative/qml/ClipboardItemDelegate.qml M +2 -0 klipper/declarative/qml/TextItemDelegate.qml https://invent.kde.org/plasma/plasma-workspace/-/commit/9f12c34a85a69b97ced7a3c4cc2981fa66e426e4