Created attachment 24160 [details]
patch for correct function with gtk_im_context_reset()

Ok, some explanation here...

1) resetIMContext(): gtk widgets that take input and call gtk_im_context_reset()
(like the editing widget) must protect their calls to gtk_im_context_reset() to
avoid recursion overflow.  We have to do that too, because at any time the LE
could call any of our i18n functions during the reset.  So we only allow
gtk_im_context_reset() to be called when we call
gtk_im_context_filter_keypress(), like GTK widgets do.

2) Tab key stuff: we have to special-case the tab key so that it can explicitly
end the exttextinput and clear the preedit buffer, otherwise you'll get the
previous cell's preedit string showing up in the new cell.

3) gtkEndExtTextInput(): this may also get called more than once in a call
chain.  For example, if we end the exttextinput at some time, we then usually
call gtk_im_context_reset() to make sure the LE forgets the preedit string. 
However, the LE might call our commmit or preedit-changed handlers, which may
again call this function.  Therefore, we need to ensure that it too does nto get
called more than once in a call chain.

4) signalIMPreeditStart/signalIMPreeditEnd: I guess we haven't had problems with
these before, but I put in token implementations and they work for us with
IIIMF.  If you don't want to consider them, dont' bother applying these parts.

Also, we don't want to call gtk_im_context_reset() every time we want to
EndExtTextInput either, since that clears the preedit buffer.  Some languages,
however, (like Sun LE Korean) commit only a _portion_ of their held text (which
is acceptable behavior), so if you call reset() you clear the whole thing and
get malformed words.

See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137398

I wonder how this works together with the fixes in CWS vcl36 ?

Actually commiting and then clearing the preedit buffer is exactly what we want
EndExtTextInput to do. At least this is how it is supposed to behave currently.
What do you want with half a word in another control (or another calc cell) ?

The problem with korean is that the LE only knows when to break words based on
what you type.  So, if you type "qkfrkd" in korean, the LE sees "qkf", which is
fine.  When you then type "r", it now knows that it has to break the word.  So
it stores the "r" around (so you don't have to type it again) and "commits" the
"qkf" that composes the first word.

But, if we call gtk_im_context_reset() during the EndExtTextInput, that "r" gets
lost because we've force-cleared the IM's buffer.  Therefore, when you continue
to type "kd", the LE doesn't know how to compose the word since you've cleared
the "r" already.

pl: see Comment #6 in the bug above:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137398#c6

Aaah, the wonderful world of IME; every IME is different and none conforms to
any standard. And they wonder that nothing works. Oh well.

yeah, it rather sucks doesn't it :(

all: i think all the workarounds that lead to hacks to other workarounds finally
convinced me that we (well, i) should redo the whole IM stuff in GtkSalFrame; no
more reset_ic, no more deleting input context and creating it again, just
decouple the vcl methods and gtk methods and put in another mediating object.
This will probably make OOo behave more like gedit (e.g. clicking around will
probably move the preedit text around), which is a bit sad, but considering the
huge problems that continue to arise with resetting the IC i think i have no
other choice.

What are your thoughts on this ?

I personally would love to test the reset functionality (somehow, XTest?) on
startup, and throw up a large & extremely rude message: "Your IM is badly broken
-   XYZ IM is known to work well, please use that instead" type thing. That
would perhaps concentrate mind in the IM community.

It's pathetic not being able to rely on IMs to correctly implement the minimal
subset that is required.

Yes, but given the multitude of IMs we have to cope with, i think we cannot rely
on reset_ic to work. Besides there are other issues: it has occured on some
systems that you can switch IM capabilites in a different window (e.g. one
inside the Gnome status bar). Clicking in there leads of course to OOo losing
focus, triggering a reset_ic. As of now this effects destruction of the current
IC and construction of a new one as soon as OOo gets the focus back - which
results in loss of the changes the user just made. This would probably also
happen if we did not create a new IC but did a reset_ic (assuming an IM where
that works), so i think we'll need to skip resetting the IC altogether since
there are too many case where this is simply not the right thing to do.

This leaves us with what you wanted in the first place: if we cannot reset the
preedit buffer, then we can at least move it around like gedit does.

well - the destroy/re-create thing always seemed like a bad idea to me :-) much
worse than re-setting it. Of course - we could do that only for IM's that we
know to be broken [ ie. not emitting preedit-changed to '' on reset [ & warning
about them in a dialog? ] ] but to be honest I completely forget all the details
here ;-)

fixed in CWS pl04, no more resets at all. I hope this solves a lot of problems,
but needs to be tested on various platforms.

please verify in CWS pl04

re-open issue and reassign to us@openoffice.org

reassign to us@openoffice.org

reset resolution to FIXED

adjust target

verified in cws 'pl04'.

Verified on MWS m121.

*** Issue 29878 has been marked as a duplicate of this issue. ***