KDE has terrific RTL support, and almost all applications can be configured to use an RTL interface including Konsole. However, when Konsole is in RTL mode the terminal editor should _not_ be made RTL. It currently is made RTL when Konsole is in RTL mode, and that leads to terrible breakage. There is no use case for an RTL terminal emulator, but despite that there are many use cases for LTR terminal emulators in RTL applications. One is Konsole itself: I prefer having the menus in Hebrew even though the terminal editor itself should be LTR. Another use case is Dolphin: the Dolphin UI should of course be in the user's native language but the embedded terminal emulator should be LTR nonetheless. Thanks!
First of all, I only have limited knowledge about LTR & RTL because I personally only use Chinese and English. So feel free to correct my wrong understanding of the problem. Konsole does contain the code for forcing LTR in the terminal area : QWidget::setLayoutDirection(Qt::LeftToRight); However, according to the Qt doc[1], that method does not influence text layout direction anymore since Qt-4.7. So this problem is basically a regression caused by upstream change. I am not sure about that statement because I have never used RTL before and have no idea how konsole behaved with old version of Qt. One solution is to force QPainter to use LTR when drawing text. The result seems fine to me, but I am, again, not sure because I do not understand neither Arabic or Hebrew so I do not know whether it causes new regression in displaying characters from those languages in the terminal area. So, if possible, could you please try this simple hack[2] and give some feedback? [1] http://doc.qt.nokia.com/latest/qwidget.html#layoutDirection-prop [2] https://github.com/adaptee/konsole/tree/LTR-terminal-area
Thank you Jekyll Wu. I'm not quite sure what you need me to test. Is there a fine manual that I should read first? Thanks.
I mean, could you fetch and compile that experimental code on you machine, and see whether it behaves as you have expected in this report without causing new regression ? Basically, you just need to perform following operations: $ git clone git://github.com/adaptee/konsole $ cd konsole $ git branch LTR-terminal-area origin/LTR-terminal-area $ git checkout LTR-terminal-area $ mkdir build $ cd build $ cmake ../ $ make $ sudo make install $ /usr/local/bin/konsole Depending upon the distribution you are using, you may encounter some problem during compiling. Refer to this page[1] for more information. [1] http://techbase.kde.org/Getting_Started/Build
(In reply to comment #3) Ping? Without feedback from people who really understand those RTL languages, I have no idea about the real effect of that experimental code.
Jekyll, the build you mentioned seems to work fine. Opening /usr/local/bin/konsole with the --reverse flag sets the UI to RTL, but the terminal emulator itself remains LTR (as it should). Thank you very much!
(In reply to comment #5) > Jekyll, the build you mentioned seems to work fine. Opening > /usr/local/bin/konsole with the --reverse flag sets the UI to RTL, but the > terminal emulator itself remains LTR (as it should). Thank you very much! Thanks for your feedback on that part. The more important part is whether it causes regression. I mean in the shell, echo "here are SOME-RTL-CHARACTERS,right?", those RTL characters should still be rendered in the RTL way, even when the terminal area as a whole is forced to be rendered in the LTR way. That is how I understand the problem, right? Please check whether the experimental code causes any regression on rendering natively RTL characters. If no regression is observed, I will submit the patch onto review board and hopefully it will get into 4.8 and 4.7.3 .
> Thanks for your feedback on that part. The more important part is whether it > causes regression. I notice no regression. I can cd into Hebrew directories and everything displays in the correct order. I see no related RTL issues or regressions. > I mean in the shell, echo "here are SOME-RTL-CHARACTERS,right?", those RTL > characters should still be rendered in the RTL way, even when the terminal area > as a whole is forced to be rendered in the LTR way. Yes, the characters render in the correct order. There is a small issue that is not a regression and probably warrants a new bug report: When the bash prompt ends in an RTL character before the soft $ sign, RTL text is shown on the wrong side of the prompt. This bug is actually _expected_ and can be solved by adding an LRM character after the prompt. I will file a new issue with a screenshot and terminal commands for non-Hebrew/Arabic users to copy and paste to reproduce the issue. > That is how I understand > the problem, right? The issue was the exact opposite, actually: LTR text was not rendering correctly (nor is it expected to) in the RTL terminal environment. But there is no use case for an RTL terminal environment anyway. > Please check whether the experimental code causes any regression on rendering > natively RTL characters. If no regression is observed, I will submit the patch > onto review board and hopefully it will get into 4.8 and 4.7.3 . No regressions! Just the one issue that I mentioned which is a separate bug. I will file it and post a link. Thank you Jekyll Wu! I wish to you a terrific morning!
I see now that the bug I mention in my previous comment is _not_ a Konsole bug but rather a shell bug. Therefore, I will not file a Konsole bug on it. The bug has a very simple workaround: simply place an LRM [1] at the end of the PS1 line in ~/.bash_profile. For more information see here: http://dotancohen.com/howto/rtl_right_to_left.html [1] http://www.fileformat.info/info/unicode/char/200e/index.htm
Git commit 044fdf90200fd9ac11546783e7e3de727c1ba13b by Jekyll Wu. Committed on 20/11/2011 at 01:46. Pushed by jekyllwu into branch 'master'. Always use Left-To-Right as the "document layout" in the terminal area REVIEW:102976 BUG:279048 FIXED-IN:4.8 M +6 -0 src/TerminalDisplay.cpp http://commits.kde.org/konsole/044fdf90200fd9ac11546783e7e3de727c1ba13b
Thank you Jekyll Wu!