Bug 206455

It's even more weird than that. After entering Japanese and having it disappear after conversion, performing an undo followed by a redo will make the text enter correctly. I thought perhaps that it could be just a display issue, but when trying a save before doing the undo/redo the resulting file didn't contain the characters typed.

I can confirm that. After undo/redo, the text is moved (length of string)-characters to the right, with preceding whitespace if necessary. I guess the problem resides in multicharacter input.

I can confirm the same behavior with KDE 4.4.1 and ibus 1.2.
It is impossible to enter Japanese in kate normally.

You can build kate/kwrite yourself with the git clone: http://gitorious.org/kate

Just install the -devel packages of kdelibs, then mkdir a build directory and switch into it. Then call cmake /path/to/your/clone -DCMAKE_INSTALL_PREFIX=<the kde install prefix>.

The install prefix can also be in your local .kde folder, this way you don't pollute your global installation. Maybe this is fixed in trunk already?

Oh, and this is probably a duplicate of bug #222620, correct?

It seems to be fixed in a recent build of trunk.


(In reply to comment #5)
> Oh, and this is probably a duplicate of bug #222620, correct?

More like #222620 is a duplicate and this one was ignored until now.

Hi Dominik,

I tried to build kate as you suggested

cmake /path/to/your/clone -DCMAKE_INSTALL_PREFIX=/my/home/dir/kate
make

and got an error
/path/to/your/clone/kate/plugins/filebrowser/katefilebrowser.cpp: In constructor ‘KateFileBrowser::KateFileBrowser(Kate::MainWindow*, QWidget*, const char*)’:
/path/to/your/clone/kate/plugins/filebrowser/katefilebrowser.cpp:79: error: ‘class KDirOperator’ has no member named ‘setNewFileMenuSupportedMimeTypes’
make[2]: *** [kate/plugins/filebrowser/CMakeFiles/katefilebrowserplugin.dir/katefilebrowser.o] Error 1
make[1]: *** [kate/plugins/filebrowser/CMakeFiles/katefilebrowserplugin.dir/all] Error 2

But the kate binary seems to be built in kate/app
When I run it directly, I am getting a normal kate window and I can edit/save files. However, the Japanese text still cannot be entered. I am getting the same error as Jason in the comment #1.

You need KDE 4.4.x to build it. But as workaround, just comment out the following line in kate/plugins/CMakeLists.txt (insert a hash):

# add_subdirectory( filebrowser )

Then you will not have the newest filebrowser plugin, but that doesn't matter :-)

Thank you, Dominik. I could build it fine following your suggestion.
But still no luck with the current bug. It does not work unfortunately.

Dima: this means that the version in git (trunk) still does not work, correct? If yes, can you apply the patches and does it work then?

Correct, Dominik, http://gitorious.org/kate does not work. Though it does already contain the fix introduced here: https://bugs.kde.org/show_bug.cgi?id=222620#c4

I tried to apply the patch https://bugs.kde.org/show_bug.cgi?id=222620#c8 but it did not work either.

Looking at the screen videos (comments 1/2 for 222620), to me the present issue seems to be different from that one.

Is there anything else I need to try?

[btw filebrowser plugin builds fine now]

> Is there anything else I need to try?

Are you really sure you are running your compiled version and not the system installation? :-) (Make sure e.g. by adding a KMessageBox somewhere)...

Yes, I am running my compiled version (compiled with kdelibs 4.4.2). I am running it from console and I have added a KMessageBox as you suggested to double check and the box did come up.
Could it be that kate user setting in ~/.kde are messing up things?

> Could it be that kate user setting in ~/.kde are messing up things?
No... It has nothing to do with the config and is a bug instead. Do we have a pending fix at all for this?

Hi all,

In response to comment #14, I can confirm that the said fix in the trunk just works fine:
http://websvn.kde.org/?view=rev&revision=1101297
(which is the same as https://bugs.kde.org/show_bug.cgi?id=222620#c4 , if I understand correctly.)

With kdelibs 4.4.2 being patched and rebuilt/reinstalled, kdesdk/kate and kdebase/apps/kwrite (both 4.4.2) do accept input from ibus without any further modification.

As for comment #13, does that mean you built kate with the git clone from gitorious and ran the executable on a system with plain kdelibs 4.4.2 installed?

If yes, in fact I was also able to reproduce your result, and indeed in that case the newly built kate and kwrite executables don't reflect the fix. Input from ibus simply disappear.

Unfortunately, I'm not familliar with KDE's build system and can't figure out why the patch against kateviewinternal.cpp is not in effect in the latter case.

But considering that it works in the first case, the patch itself seems valid.

Hi Youichi,

Regarding comment #13 - yes I built kate with the git clone from
gitorious and ran the executable on a system with kdelibs 4.4.2 from the current kubuntu backports. I did *NOT* rebuild the latest kdelibs from source.

Just for info: a better howto for compiling without touching your global kde installation:
http://dhaumann.blogspot.com/2010/04/quick-compiling-kate-in-stable-kde.html

Dominik, thank you for your guide. Following it, the japanese input worked for me. I did various tests to narrow down the problem and found out that the whole thing (at least for me) was in the $KDEDIRS. When I set it to the path where I had the compiled kate installed I was able to enter japanese text.
Other variables and commands did not make much difference for me.
So, for me it was like:
cmake
make
make install
export KDEDIRS=/path/to/new/kate_dir
/path/to/new/kate_dir/bin/kate

Thanks Dominik, following the updated howto, now I can also confirm that kate from gitorious works as expected.

Created attachment 42925 [details]
Proposed new patch.

Hi Dima and Youichi: Ok, in summary, we have this:

In trunk it works due to commit
http://websvn.kde.org/trunk/KDE/kdelibs/kate/view/kateviewinternal.cpp?r1=1101297&r2=1101296&pathrev=1101297

So we have to backport this commit.

In bug #222620 in comment 8 (http://bugs.kde.org/show_bug.cgi?id=222620#c8) there is another patch that also respects overwrite mode. This patch is quite different and even removes the patch above.

Instead of backporting the above commit, can you apply the attached patch here and retry again?

If this works for all of you, I will commit this.

Hi Dominik,

I applied your new proposed patch to my git clone, and both Kate and KWrite accept Japanese input from ibus.

Confirmed with ibus 1.3.1, ibus-anthy 1.2.0.20100313 and ibus-qt 1.3.0.

I've committed the patch:
http://gitorious.org/kate/kate/commit/d3aae57f8f0501f8f73faecb3759ab6a1a66b4b5

*** Bug 222620 has been marked as a duplicate of this bug. ***

Now that I've committed the patch in comment #22, I'd like you all to test current git again (the run.sh script is fixed now in my quick compile howto).

If you give green light then, I'll backport for 4.4.3. Thanks for all your efforts so far!

Works for me. Thank you Dominik.

There is another thing I have noticed. The converted text is supposed to be highlighted, and you can expand or shrink (Shift + -->/Shift + <--) the highlighted area to include/exclude the letters you want to convert. Also you can switch between text fragments on the to be converted line with left/right arrows and they get highlighted.

This works on Konqueror or Dolphin, for example, but no highlighting appears in Kate (though the functionality itself is intact). I wonder if someone else can also confirm this.

(In reply to comment #25)
> There is another thing I have noticed. The converted text is supposed to be
> highlighted, and you can expand or shrink (Shift + -->/Shift + <--) the
> highlighted area to include/exclude the letters you want to convert. Also you
> can switch between text fragments on the to be converted line with left/right
> arrows and they get highlighted.

This is another problem.

Probably, it is necessary for the code controlling preedit area of 
kate to be reviewed. Because, it is too simpler than the code of 
QLineEdit and QTextEdit in Qt4.

But, it is nothing to do with this bug and patch.

I can confirm the same as Dima. Thanks a lot for your work, Dominik.

Dima, as for the highlighting issue, as you might already know, current workaround is to have QT_IM_MODULE=xim for your X session (provided that you started ibus-daemon with -x option.) 

This may be compromising though, since the highlights seem to be always in black and white as opposed to the colorized ones you get with QT_IM_MODULE=ibus.

(In reply to comment #27)
> Dima, as for the highlighting issue, as you might already know, current
> workaround is to have QT_IM_MODULE=xim for your X session (provided that you
> started ibus-daemon with -x option.) 

I see.

Isn't it a problem of ibus-qt?
Highlighting also works correctly when I use scim.

The highlight color is appointed by input method plugin, 
such as scim-qtimm, ibus-qt4 and uim-qt.
So, probably, the color which is appointed by ibus-qt4 is white.

SVN commit 1117263 by dhaumann:

Attempt to fix input method event handling to allow japanese text.
If possible, please try the 4.4 branch.

BUG: 206455


 M  +34 -30    kateviewinternal.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1117263

The change is now committed. Please open new bug reports for different issues.

If possible, would be nice if you can try the KDE 4.4 branch to confirm it still works. Thanks a lot for your time so far! :)

SVN commit 1117269 by dhaumann:

Attempt to fix input method event handling to allow japanese text.
If possible, please try the 4.4 branch.

CCBUG: 206455


 M  +36 -30    kateviewinternal.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1117269

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

(In reply to comment #30)
> The change is now committed.

Thank you for committing in 4.4 branch.
But you forget to apply the following parts.

--------------------------------------------
@@ -3778,13 +3778,6 @@
     return;
   }

-  // 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() ) ) {
-    e->accept();
-    return;
-  }
-
   //kDebug( 13030 ) << "Event: cursor" << m_cursor << "commit" << e->commitString() << "preedit" << e->preeditString() << "replacement start" << e->replacementStart() << "length" << e->replacementLength();

   if ( m_view->selection() )
--------------------------------------------

Would you check it?

SVN commit 1117595 by dhaumann:

CCBUG: 206455

 M  +0 -7      kateviewinternal.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1117595