Can't track flow of characters in from Input Method Editor

Richard Wordingham richard.wordingham at ntlworld.com
Wed Oct 7 17:17:14 PDT 2015


Thank you all for your inputs.

On Wed, 7 Oct 2015 09:57:14 +0200
Miklos Vajna <vmiklos at collabora.co.uk> wrote:

> Writer "main text" gets all keyboard input in SwEditWin::KeyInput(),
> sw/source/uibase/docvw/edtwin.cxx. It's VCL that calls that member
> function, and in your case it's probably the VCL KDE backend in
> particular.

On Wed, 7 Oct 2015 22:20:01 +0800
Hung Mark <marklh9 at gmail.com> wrote:

> Since you mentioned that Writer exhibit the problem but Calc
> doesn't,you might want to take a look at
> sw/source/core/doc/extinput.cxx.

SwEditWin::KeyInput() is receiving the input not generated by the IME,
e.g. Latin and Thai as I have my keyboards set up, but the normal
character input generated by the IME (BMP Tai Tham and SMP Tirhuta) is
going to SwExtTextInput::SetInputData instead!  Backspaces generated by
hitting the 'rubout' key (labelled with a right-to-left arrow) follow
the non-IME route.  I do not yet know what happens to backspaces
generated by the IME.

On Wed, 07 Oct 2015 11:10:08 +0200
Jan-Marek Glogowski <glogow at fbihome.de> wrote:

> I guess you're running Kubuntu 12.04, as you talk about KDE in this
> post.

The KDE code was a red herring.  The characters are coming in from the
basic X system via GtkSalFrame::signalKey, as one would expect for a
primarily Gnome system, despite the graphical shell being Unity.  So,
it's basically Ubuntu.

> LO 5.0 builds just fine in Precise / 12.04. See
> https://launchpad.net/~libreoffice/+archive/ubuntu/ppa?field.series_filter=precise
> for newer packages.

I'll give it another try.  Pre-release versions obtained via Git
wouldn't compile.

> We also had problems with Qt4 / all KDE applications and ibus. At the
> end we backported the 14.04 / trusty version of fcitx and use this
> currently :-(

I hope we haven't got a race condition.  I don't understand the order
of my monitoring outputs.  I was able to run LibreOffice under gdb
running from Emacs Version 23, whereas the combination failed under
Emacs 24.  (The two Emacsen use different interfaces to gdb,
which may be the reason for the difference.)  However, not only was I
not able to set a break point where I wanted (probably my lack of
competence), I could not reproduce the error.  I got no lone
surrogate!  This better behaviour has not been reproduced.

Richard.


More information about the LibreOffice mailing list