Version: (using KDE 4.2.0) Installed from: Ubuntu Packages Please see screenshots with descriptions below. These issues appear to be specific to RTL-enabled systems.
Created attachment 32085 [details] Screenshot illustrating problem 1) It can be seen that the punctuation in the protocol is backwards. For instance "remote://" shows up as "/:remote". 2) The submenus' rounded corners are facing the wrong side. 3) The username and machine name are displayed in the wrong order. On this system the username Is "jaunty".
Created attachment 32086 [details] Screenshot illustrating problem In this screenshot, it can be seen that: 1) The English-language menu items fade on the left when they should fade on the right. 2) The blue "back arrow" is on the left side of the menu items, whereas it should be on the right. 3) There is a white bar across the second-from-the-bottom menu item. Appears consistently in the Applications submenu, not in any other submenu. Appears in this submenu consistently in Hebrew KDE4, and not in English KDE4.
Created attachment 32780 [details] Screenshot illustrating problem These issues affect the Lancelot menus as well. In this Hebrew setup, the beginning (right side) of Hebrew text is faded, instead of the end (left side).
The punctuation in Klipper is affected as well, which leads me to believe that this is not a Plasma issue but a larger Qt issue. Note that this issue could be solved by adding the Unicode LRM character after all English/LTR strings in Hebrew/Arabic/Persian desktops, and adding the RLM character after all Hebrew/Arabic/Persian strings in English/LTR desktops. RLM character: http://www.fileformat.info/info/unicode/char/200f/index.htm LRM character: http://www.fileformat.info/info/unicode/char/200e/index.htm
Created attachment 32781 [details] Screenshot for Klipper illustrating problem, which arrows showing specific instances
Painting in Lancelot fixed.
The issues from comment #1 have been fixed! The issues from comment #2 have been fixed! Comment #3 is still valid: The Hebrew-language menu items fade on the right when they should fade on the left. Shall I file a separate issue on this, retitle this bug, or leave it as is? Thanks, Ivan!
@Dotan Is this Lancelot from 4.3? It should have been fixed in 4.3... (and works for me - I'm testing with --reverse flag enabled)
Yes, this is the KDE 4.3 beta. Would you like a screenshot?
Yes please :) P.s. And please try running "lancelot --reverse" (kill lancelot before invoking the command) to see wgether there is any change
How do I kill Lancelot? I suppose that I could kill plasma, but pkill lancelot does nothing.
pkill lancelot should do the trick. Mind that you will not /see/ that it is killed - the moment you click/hover the launcher, lancelot will be automatically stared. After pkill, check that ps aux | grep '[l]ancelot' doesn't return anything (anything important at least :) )
With the --reverse flag, These are the current issues: א) The punctuation in the protocol is backwards. For instance "remote://" shows up as "/:remote". ב) The English-language menu items fade on the left when they should fade on the right. So it seems that the only issues that were fixed are the issues that do not apply to the current version of Lancelot! (Features that were removed such as the hostname or features that are no longer directional, such as the submenus' rounded corners). Screenshots coming.
Created attachment 34839 [details] This is Lancelot without the --reverse flag. Note Stellarium and Ksnapshot in the upper left corner for examples of fading. As you know, English should fade to the right and Hebrew to the left. In this example, the English incorrectly fades to the left, and the Hebrew correctly fades to the left. An Arabic user has confirmed that he sees the same behaviour in his language as well.
Wow, I messed up the previous comment. It should have read like this: Note Stellarium and Ksnapshot in the upper left corner for examples of fading. As you know, English should fade to the right and Hebrew to the left. In this example, the English correctly fades to the right, and the Hebrew incorrectly fades to the right. An Arabic user has confirmed that he sees the same behaviour in his language as well.
Created attachment 34840 [details] This is Lancelot with the --reverse flag. In this screenshot _with_ the --reverse flag it can be seen that the English incorrectly fades to the left, and the Hebrew correctly fades to the left.
Created attachment 34841 [details] This is Lancelot with the --reverse flag in the Computer submenu Here it can be seen that trash:/ is shown as /:trash and /home/jaunty2 is shown as home/jaunty2/
--reverse is meant *only* for RTL languages (that is, it is normal that English language fades left when --reverse is used). The thing I don't understand is why the --reverse is not enabled automatically when a RTL language is active... It should be... And I'm not sure whether I can do anything about things that are not translated when in RTL mode.
> --reverse is meant *only* for RTL languages (that is, it is normal > that English language fades left when --reverse is used). Naturally, --reverse is meant only for RTL languages. However, I disagree that it means that English should fade to the left. I expect the _end_ of the text to fade, not a particular side of it. > The thing I don't understand is why the --reverse is not enabled > automatically when a RTL language is active... It should be... It should be! But this may be part of a wider KDE 4.3 issue: https://bugs.kde.org/show_bug.cgi?id=196222 > And I'm not sure whether I can do anything about things that are > not translated when in RTL mode. No, that is the translator's job. But I do not see anything not translated. The trash:/ issue is not a translation issue. It is an LTR string with punctuation. The punctuation, being non-directional, goes after the directional Latin letters. In an RTL interface, after means "to the left of". The solution is to wrap LTR strings in LRM characters when shown in an RTL interface. The opposite is true for showing RTL strings in an LTR interface: they need to be wrapped in RLM characters.
1. I agree with you on "I disagree that it means that English should fade to the left". But it does mean that Lancelot has no clue about which language is in which icon - it just shows the text, the internationalization system gives it. IMO, there should be NO text in English at all. (when another language is selected) So, when that is concerned, there are a lot of things that are not translated (Home, Firefox, Volume, the rest of L's UI) 2. The rest of the problems are KDE-wide problems - Dolphin shows screwed up urls in icon descriptions, and RTL loading is also global according to bug 196222 you've mentioned. I'll try to investigate the 1. to see whether there is a normal solution, but that's all I can do...
Thanks. There will always be Latin-based text in non-Latin (even RTL) interfaces as some terms are defined in Latin characters. A typical example would be /home/user.
It is not the question of latin vs non-latin, but rather RTL vs LTR. But, I agree that the paths (and similar stuff) should be left alone. We definitely need more core developers from RTL areas...
p.s. This definitely is a global issue - I've checked Kickoff and it behaves the same... It looks like the order of the characters is changed while painting (that is, it is built in Qt)
Agreed, this is a global issue. Should I change the product, or how to proceed?
I'm marking this as /upstream/ problem. So, you can open a new report. (it will receive more audience if if doesn't say 'KMenu')
Thanks, Ivan, I will try to reproduce the issues in other applications as well and file bugs that show them in multiple apps. Thanks for your patience and your code!