Version: (using KDE Devel) Installed from: Compiled sources OS: Linux At kdebase revision 706306 input method event support is not implemented in Konsole. It would be nice if we can get informed when it is implemented so we can test it before the final release. Thanks.
I have committed an initial implementation of input method event support, kdebase revision 708351. Could you please test?
I have tested the input support using Simplified Chinese. The input method is fcitx. It works fine when a konsole app just starts. But after I clicked the konsole's menu bar some times, the access key-binds for input method switching : "Ctrl+space" won't work. It just output "0x00" in the konsole. And I can't input Chinese char any more. If I close that konsole app and restart one, it can input again. So there must be a bug.
Sorry, the buggy output generated by pressing "ctrl+space" is *"\x00"*, NOT "0x00".
At kdebase revision 712549, Konsole accepts Japanese input but it's not easy because of the following problems. 1. It seems that XIM is used instead of Qt immodule since the candidate window (which shows converted suggestions) appears at the bottom of the application instead of below the input line. Maybe something is wrong with my configurations though. 2. Preedit strings are not fully displayed. With the "On The Spot" mode, typed characters appear in the konsole window as you type and the first couple of candidates are also displayed inline (not in the separate candidate window). I can only see part of these characters. 3. As reported in comment #2, I also got "\x00" at some point. Another issue is that Japanese text is not displayed properly. I use vim for translation and have no problem in KDE3's Konsole, but in KDE4's some Japanese characters are not drawn at all or only partially drawn. It seems to me that the problem occurs where a single byte character is followed by Japanese characters. I'll attach two screenshots to compare. Also, the text colors for po files are very difficult to read in KDE4's Konsole.
Created attachment 21657 [details] Screenshot of KDE3's Konsole + Vim
Created attachment 21658 [details] Screenshot of KDE4's Konsole + Vim
> Maybe something is wrong with my configurations though. John Tapsell reported this as well. Is this also true for other KDE 4 applications? There isn't any XIM/immodule specific code in Konsole so quite possibly a configuration problem. There is a micro-focus hint which guides Qt about where the input is happening, that might be wrong. > I can only see part of these characters. Do the screenshots show this? An annotated screenshot would be helpful. > Also, the text colors for po files are very > difficult to read in KDE4's Konsole. There is a heuristic in KDE 4 which tries to guide Vim and other terminal apps about whether the session background color is light or dark. In your case it is giving the wrong result. What background color are you using? (RGB value)
> Is this also true for other KDE 4 applications? > There isn't any XIM/immodule specific code in Konsole so quite possibly a configuration problem. I had installed scim-qtimm-qt4 (experimental) but was probably using the stable version of scim-qtimm for Qt3. However, this one is said to support Qt4 as well and IIRC it displayed the candidate window below the input line a few months ago. For that matter, uim-qtimmodule doesn't seem to work anymore. Anyway, I uninstalled the older version to make things less complicated and now have three options: XIM, scim-qtimm-qt4 and scim-bridge-qt4. The candidate window appears at different positions depending on which I use. XIM: at the bottom of Konsole (due to a limitation of XIM) scim-bridge: below the input line (OK) scim-qtimm: at the top left (*) * There might be a problem in scim-qtimm-qt4 but the candidate window appears below the input line in some other apps and scim-qtimm-edittest. This is a small utility which comes with scim-qtimm-qt4 and allows you to test input methods in QLineEdit and QTextEdit. > Do the screenshots show this? No. I'll make a new screenshot. > What background color are you using? (RGB value) Konsole started with the black background and intense text colors so I just changed the color scheme to "Black on Light Yellow". After creating several profiles, it started to use the same text colors as in KDE3's in light background and now the text colors do change when I switch to a dark background. I think this happened after I created a new color scheme and restarted Konsole...
It was hard to describe the problem in a single screenshot so I created a web archive. Can you please open it in Konqueror? I used scim-qtimm-qt4 which displays the candidate window at the right position. For comparison I did the same things in gnome-terminal using scim-gtk-immodule. scim-anthy and scim-skk are Japanese input modules for scim.
Created attachment 21665 [details] Screenshots of Konsole and gnome-terminal
Thanks Yukiko, that makes things clearer. The pre-edit string was being drawn on the assumption that one character == one column on screen, which is incorrect. Fixed by revision #714942 (Use string_width() to calculate columns needed to draw pre-edit string).
" I think this happened after I created a new color scheme and restarted Konsole... " I think I see the problem. The hint Konsole (KDE 4) provides to the shell is via an environment variable (COLOR_FGBG) which cannot be changed after the session is started. Therefore if you change the color scheme from one with a light background to one with a dark background (or the other way) the color hint will be wrong until you start a new session. In Vim you can change the colors manually using :set bg=light or :set bg=dark
Thank you for the fix and for the tip about Vim. I'll confirm as soon as a kdebase > revision 714942 package becomes available. I'm still at revision 712549. BTW, there is another issue I forgot to mention. While typing Japanese we sometimes need to adjust the pre-edit string (before converting) to fix a typo or insert more characters. The problem is that we can move the caret but can not *see* it in Konsole. In other KDE4 apps which support Qt immodule (e.g. KMail) I can see it and thus edit the pre-edit string easily. This is not a new problem in KDE4 version though. :) To other testers: With scim-qtimm-qt4 (in CVS) I can not see the caret in other KDE4 apps either. I can see it with scim-bridge-qt4 and the latest version of uim-qtimmodule (in SVN). (uim-skk does not allow to move the caret but I think it's a design.) XIM does not support it. (Correct me if I'm wrong.)
At kdebase revision 709234 the pre-edit string is fully drawn and I can enter Japanese comfortably [*] using uim/scim-skk (word-by-word conversion). However, there is a problem when using a multi-segment conversion engine (e.g. anthy). When I convert a long phrase/sentence, Konsole inverts the whole pre-edit so I can not see which segment is active. I'll attach a screenshot. [*] Japanese PO files are still not displayed properly in Vim as shown in the second attachment so I can not actually use it for translation though.
Created attachment 21936 [details] Screenshot of multiple segments inverted
> [*] Japanese PO files are still not displayed properly in Vim as shown in the second attachment so I can not actually use it for translation though. A bug with double-width characters which looks similar to the problem in the screenshot was recently fixed. Can you try with a current Konsole revision and see if you can now use Vim for translation?
Yes, Konsole now displays Japanese PO files properly. Thanks for the fix. However, when I try to insert text, the pre-edit is drawn *over* the existing one. I'll attach a screenshot.
Created attachment 23124 [details] Screenshot of inserting text
*** Bug 155626 has been marked as a duplicate of this bug. ***
comment #17 and comment #18 describe the same problem which I reported in http://bugzilla.novell.com/show_bug.cgi?id=380517 Apparently onthespot doesn’t work this behaviour looks like overthespot. If testing with kwrite for comparison: kwrite --inputstyle overthespot & and kwrite --inputstyle onthespot & there is a noticeable difference: When overthespot is used, the preedit string pops up in a different window, when onthespot is used the preedit string is inserted immediately at the cursor position *and* the text to the right of the cursor is immediately moved to the right as far as necessary. The preedit string doesn’t overlap any existing text. With konsole, both konsole --inputstyle overthespot & and konsole --inputstyle onthespot & behave identical, in both cases the preedit string is drawn at the cursor position *but* overlaps existing text (just as Yukiko describes in comment #17 and comment #18).