Bug 206455 - [regression] kate part ignores japanese input from ibus
Summary: [regression] kate part ignores japanese input from ibus
Status: CLOSED FIXED
Alias: None
Product: kate
Classification: Applications
Component: kwrite (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
: 222620 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-09-06 06:12 UTC by David Palacio
Modified: 2010-08-02 15:19 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Proposed new patch. (1.70 KB, patch)
2010-04-20 22:24 UTC, Dominik Haumann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Palacio 2009-09-06 06:12:52 UTC
Version:           4.3.67 (KDE 4.3.67 (KDE 4.4 >= 20090904)) (using 4.3.67 (KDE 4.3.67 (KDE 4.4 >= 20090904)), compiled sources)
Compiler:          gcc
OS:                Linux (x86_64) release 2.6.26-2-amd64

Using ibus 1.2 on Kwrite/Kate from trunk (to be 4.4), with the japanese anthy engine. When the romaji to kana mode is active, kate/kwrite discards it. When the latin mode is active, kate/kwrite accept it. Every other KDE, Qt program, Firefox, GTK programs accept Japanese input just fine.

Kwrite 4.3.1 works well too.
Comment 1 Jason Stubbs 2010-02-08 01:47:53 UTC
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.
Comment 2 David Palacio 2010-02-08 01:59:31 UTC
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.
Comment 3 Dima 2010-04-01 11:36:42 UTC
I can confirm the same behavior with KDE 4.4.1 and ibus 1.2.
It is impossible to enter Japanese in kate normally.
Comment 4 Dominik Haumann 2010-04-01 18:29:09 UTC
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?
Comment 5 Dominik Haumann 2010-04-01 18:30:24 UTC
Oh, and this is probably a duplicate of bug #222620, correct?
Comment 6 David Palacio 2010-04-01 20:13:14 UTC
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.
Comment 7 Dima 2010-04-02 04:45:37 UTC
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.
Comment 8 Dominik Haumann 2010-04-02 11:45:41 UTC
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 :-)
Comment 9 Dima 2010-04-06 02:30:41 UTC
Thank you, Dominik. I could build it fine following your suggestion.
But still no luck with the current bug. It does not work unfortunately.
Comment 10 Dominik Haumann 2010-04-06 21:28:10 UTC
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?
Comment 11 Dima 2010-04-07 03:23:28 UTC
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]
Comment 12 Dominik Haumann 2010-04-08 00:58:29 UTC
> 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)...
Comment 13 Dima 2010-04-08 03:30:18 UTC
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?
Comment 14 Dominik Haumann 2010-04-08 16:19:53 UTC
> 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?
Comment 15 Youichi Tazawa 2010-04-18 05:30:35 UTC
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.
Comment 16 Dima 2010-04-20 02:31:52 UTC
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.
Comment 17 Dominik Haumann 2010-04-20 08:14:31 UTC
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
Comment 18 Dima 2010-04-20 10:03:30 UTC
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
Comment 19 Youichi Tazawa 2010-04-20 11:11:00 UTC
Thanks Dominik, following the updated howto, now I can also confirm that kate from gitorious works as expected.
Comment 20 Dominik Haumann 2010-04-20 22:24:03 UTC
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.
Comment 21 Youichi Tazawa 2010-04-21 08:42:39 UTC
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.
Comment 22 Dominik Haumann 2010-04-21 08:59:55 UTC
I've committed the patch:
http://gitorious.org/kate/kate/commit/d3aae57f8f0501f8f73faecb3759ab6a1a66b4b5
Comment 23 Dominik Haumann 2010-04-21 09:01:08 UTC
*** Bug 222620 has been marked as a duplicate of this bug. ***
Comment 24 Dominik Haumann 2010-04-21 09:03:09 UTC
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!
Comment 25 Dima 2010-04-21 10:48:59 UTC
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.
Comment 26 Daisuke Kameda 2010-04-21 14:48:16 UTC
(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.
Comment 27 Youichi Tazawa 2010-04-21 15:32:43 UTC
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.
Comment 28 Daisuke Kameda 2010-04-21 15:57:36 UTC
(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.
Comment 29 Dominik Haumann 2010-04-21 19:48:36 UTC
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
Comment 30 Dominik Haumann 2010-04-21 19:49:49 UTC
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! :)
Comment 31 Dominik Haumann 2010-04-21 19:54:54 UTC
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
Comment 32 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
Comment 33 Daisuke Kameda 2010-04-22 00:51:48 UTC
(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?
Comment 34 Dominik Haumann 2010-04-22 17:01:46 UTC
SVN commit 1117595 by dhaumann:

CCBUG: 206455

 M  +0 -7      kateviewinternal.cpp  


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