| Summary: | [PATCH] [4.4rc1 regression] cannot enter text in languages requiring commit (Japanese) using input methods through their Qt4 modules | ||
|---|---|---|---|
| Product: | [Applications] kate | Reporter: | JR <zorael> |
| Component: | general | Assignee: | KWrite Developers <kwrite-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | chrisburel, daisuke, daniel, ek.kato |
| Priority: | HI | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Broken input in KWrite, using UIM with its Qt4 im module
Working input in KWrite, using UIM with its XIM wrapper Another patch that enable to enter text in Kate |
||
Created attachment 39866 [details]
Broken input in KWrite, using UIM with its Qt4 im module
Created attachment 39867 [details]
Working input in KWrite, using UIM with its XIM wrapper
I have the same problem, KDE 4.4.0, Qt 4.6.1, I tried with UIM 1.5.6 and 1.5.7. As I described in uim's bugzilla (http://bugs.freedesktop.org/show_bug.cgi?id=26265#c15), the changes in kdelibs-4.4.0/kdelibs-4.4.0/kate/view/kateviewinternal.cpp from kdelibs-4.3.x causes this problem. So, in case of calling KateDocument::typeChars() in line 3781, please check whether m_imPreeditRange is still valid. Following patch will solve the problem for the event sequences like uim uses. --- kateviewinternal.cpp.orig 2009-12-31 22:29:14.000000000 +0900 +++ kateviewinternal.cpp 2010-03-07 15:36:48.073367864 +0900 @@ -3778,7 +3778,7 @@ // if the input method event is text that should be inserted, call KateDocument::typeChars() with // the text. that method will handle the input and take care of overwrite mode, etc. - if ( e->commitString().length() > 0 && doc()->typeChars( m_view, e->commitString() ) ) { + if ( e->commitString().length() > 0 && !m_imPreeditRange && doc()->typeChars( m_view, e->commitString() ) ) { e->accept(); return; } SVN commit 1101297 by dhaumann: Attempt to fix xim input methods, only in trunk for now as I don't have much knowledge about this topic. The patch looks sane, though. So if there are no further problems, we maybe should consider backporting to 4.4 branch? BUG: 222620 M +1 -1 kateviewinternal.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1101297 Thanks. Please consider porting to 4.4 branch if there are no further problems. Because if I use ibus input method instead of uim, the situation is even worse unless the patch is applied. In case of ibus, I cannot input text using preedit neither with xim module nor ibus module, confirmed on Fedora 12's kdelibs-4.4.0-9 and ibus-1.2.0.20091206-2. Although I don't know the original intention of the change in kdelibs 4.4.0, I guess calling doc()->typeChars() is targeted for the input methods like table based direct input, which don't require preedit text. For the input methods like Japanese, it uses preedit text before committing actual text, and the sequence of commit the actual text and clear and/or update of preedit text depends on the situation. We need backport to 4.4 branch, because we can't input Japanese on katepart in KDE4.4. I found that this code was committed in revision 991349. http://websvn.kde.org/?view=revision&revision=991349 But I can't understand the intention from comments. Could you confirm it in the developer team? Created attachment 41802 [details]
Another patch that enable to enter text in Kate
I made another patch that enabled to input text in Kate/Kwrite.
If this patch is used, it is possible to overwrite even with
input methods like Japanese, which use preedit text before
committing actual text.
Probably, you can input text in overwrite mode, even if you
use the input methods like table based direct input.
Please review it.
Daisuke: Ok, there is another usage of insertText in that function:
if (!e->preeditString().isEmpty()) {
doc()->inputMethodStart();
doc()->insertText(m_imPreeditRange->start(), e->preeditString());
doc()->inputMethodEnd();
// The preedit range gets automatically repositioned
}
What about typeChars here?
I've committed the patch: http://gitorious.org/kate/kate/commit/d3aae57f8f0501f8f73faecb3759ab6a1a66b4b5 Mark as duplicate of bug #206455. All further discussion there, please. *** This bug has been marked as a duplicate of bug 206455 *** (In reply to comment #9) > Daisuke: Ok, there is another usage of insertText in that function: > > if (!e->preeditString().isEmpty()) { > doc()->inputMethodStart(); > doc()->insertText(m_imPreeditRange->start(), e->preeditString()); > doc()->inputMethodEnd(); > // The preedit range gets automatically repositioned > } This code inserts a text only as "preedit text". I explain these roughly: "preedit text" are characters which is converting. We input Japanese after converting characters more than once by using input method. Deciding characters as Japanese is called "commit". > What about typeChars here? This method inserts a text only as "commit text". typeChars inserts a text in consideration of overwrite mode. So my patch enable to overwrite characters even if you use input method. That makes sense. Thanks a lot for the explanation. SVN commit 1117272 by cullmann:
dhaumann:
Attempt to fix japanese input mode
CCBUG: 206455
CCBUG: 222620
M +12 -5 kateview.cpp
M +3 -3 kateview.h
M +6 -9 kateviewinternal.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=1117272
|
Version: (using Devel) OS: Linux Installed from: Compiled sources Kubuntu 9.10, running KDE SC 4.4rc1 with ppa packages. libqt4 packages are of version 4:4.6.0-1ubuntu3~karmic1~ppa1. Bug: When using input methods to type in languages that give you a set of candidates that you pick from and commit (such as Japanese), text entry is broken in (at least) Kate and KWrite. I have tested this using UIM, SCIM and IBus, which all have their own specific Qt4 modules. Recompiling UIM didn't help, either. Japanese has thousands of complex characters called Kanji, imported from China in iterations throughout history. Since a keyboard cannot possibly house thousands of keys, input is done by entering the syllables of words, either on a western keyboard or on a Japanese one. An input method engine then compares your entry to its dictionary of words and gives you a list of candidates matching the pronunciation of the syllables you entered. Then you pick one and hit enter to commit. The bug comes in when you enter text in said apps. It gets properly converted, and then you hit enter to commit. The text-to-be-committed gets committed. But it doesn't disappear from the entry cursor - rather it "sticks" to it. If you now press any other key than Enter, the newly committed text gets erased and you start at square one. Input is impossible. This is difficult to explain, so I'm attaching a screencast of it. How to reproduce: 1. Install UIM, SCIM or IBus and set it up to be used as default input method 2. Install Anthy (Japanese engine) packages for chosen input method (such as uim-anthy, scim-anthy, ibus-anthy) 3. Restart X and login. 4. If set up properly in step 1, the environmental variable QT_IM_MODULE should mention your input method ("uim", "scim", "scim-bridge", "ibus", etc), and the XMODIFIERS variable should be "@im=<input method>" ("@im=uim", etc) 5. Open up Kate or KWrite and enable Anthy, either via keybinds, via toolbars or via applets 6. Set it to accept Romaji (western keys) as input, and translate it in the syllable alphabet, Hiragana 7. Type something, such as 'toukyou'. It should be translated as 'とうきょう' as you type, which is 'toukyou' in Hiragana. It should automatically be selected or underlined (depending on input method behavior) which signifies it being "input in progress"; text not yet committed 8. Hit space to convert the syllables to Kanji. The first candidate should be '東京' (the capital, Tokyo, which is what we typed earlier as syllables) 9. Hit enter to commit. '東京' should end up as normal text, without being selected or underlined. The entry cursor should behave as normal, allowing you to start typing the next word or symbol. What happens instead: 9. The text is committed, but it also sticks to the entry cursor. The to-be-committed text never goes away. Hitting any other key now erases the '東京' we committed earlier and starts entry anew from the beginning. Workaround: 1. Instead of using the Qt4 module for your input method, use your its XIM wrapper (if available), such as by exporting QT_IM_MODULE="xim" before starting the program. This may be a Qt4.6.0 bug, or it may be a Kate/KWrite (katepart?) 4.4 bug. I have not found it prevalent as described here in any other app, though text entry with said input methods have *very* sluggish performance in several other KDE apps. That bug description is different though, so I will file that separately. ChemBro on #kde@irc.freenode.net confirmed it as not prevalent in 4.3.4 but occuring in 4.4rc1.