Bug 222620 - [PATCH] [4.4rc1 regression] cannot enter text in languages requiring commit (Japanese) using input methods through their Qt4 modules
Summary: [PATCH] [4.4rc1 regression] cannot enter text in languages requiring commit (...
Status: RESOLVED DUPLICATE of bug 206455
Alias: None
Product: kate
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: HI normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-14 00:00 UTC by JR
Modified: 2010-04-21 19:55 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Broken input in KWrite, using UIM with its Qt4 im module (100.84 KB, video/ogg)
2010-01-14 00:01 UTC, JR
Details
Working input in KWrite, using UIM with its XIM wrapper (75.87 KB, video/ogg)
2010-01-14 00:07 UTC, JR
Details
Another patch that enable to enter text in Kate (1.39 KB, patch)
2010-03-21 13:58 UTC, Daisuke Kameda
Details

Note You need to log in before you can comment on or make changes to this bug.
Description JR 2010-01-14 00:00:06 UTC
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.
Comment 1 JR 2010-01-14 00:01:22 UTC
Created attachment 39866 [details]
Broken input in KWrite, using UIM with its Qt4 im module
Comment 2 JR 2010-01-14 00:07:26 UTC
Created attachment 39867 [details]
Working input in KWrite, using UIM with its XIM wrapper
Comment 3 Chris Burel 2010-02-26 08:00:30 UTC
I have the same problem, KDE 4.4.0, Qt 4.6.1, I tried with UIM 1.5.6 and 1.5.7.
Comment 4 ekato 2010-03-09 14:13:19 UTC
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;
   }
Comment 5 Dominik Haumann 2010-03-09 22:19:50 UTC
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
Comment 6 ekato 2010-03-10 02:27:19 UTC
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.
Comment 7 Daisuke Kameda 2010-03-12 15:07:04 UTC
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?
Comment 8 Daisuke Kameda 2010-03-21 13:58:21 UTC
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.
Comment 9 Dominik Haumann 2010-04-20 22:16:49 UTC
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?
Comment 10 Dominik Haumann 2010-04-21 08:59:53 UTC
I've committed the patch:
http://gitorious.org/kate/kate/commit/d3aae57f8f0501f8f73faecb3759ab6a1a66b4b5
Comment 11 Dominik Haumann 2010-04-21 09:01:08 UTC
Mark as duplicate of bug #206455. All further discussion there, please.

*** This bug has been marked as a duplicate of bug 206455 ***
Comment 12 Daisuke Kameda 2010-04-21 14:25:55 UTC
(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.
Comment 13 Dominik Haumann 2010-04-21 19:40:09 UTC
That makes sense. Thanks a lot for the explanation.
Comment 14 Christoph Cullmann 2010-04-21 19:55:45 UTC
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