Apache OpenOffice (AOO) Bugzilla – Issue 73863
IM: gtk_im_context_reset on endExtTextInput (?)
Last modified: 2008-07-07 14:28:59 UTC
https://www.redhat.com/archives/fedora-desktop-list/2007-January/msg00104.html I know your love of IMs are only equaled by my own love for them, but.... a) my korean users are quite annoyed with me that when a.1) they activate scim-hangul type o, which is then highlighted as being in the pre-edit buffer, 1.2) When they click elsewhere in e.g. calc they want it committed to the document, right now it follows them around the document b) my chinese users are annoyed that when they type wo in scim-pinyin and have that highlighed as being in the pre-edit buffer that the buffer moves around with them to the rest of the document, they want it to just "go away" i.e. they want OOo to behave like gedit. So attached is a patch to use gtk_im_context_reset on GtkSalFrame::IMHandler::endExtTextInput The docs say... http://developer.gnome.org/doc/API/2.0/gtk/GtkIMContext.html#gtk-im-context-reset "Notify the input method that a change such as a change in cursor position has been made" which would seem to be a DoTheRightThing sort of method.
Created attachment 42456 [details] patch to do this
*** Issue 67316 has been marked as a duplicate of this issue. ***
Since the last time this came up the gtk_im_context_reset was causing a plethora of problems I'm kind of opposed to the patch. And it was exactly the koreans that were complaining then; see issue 45768. Funny thing is gedit used to move the preedit around like we do now. Seems there are two opinions on that behaviour even in Korea.
heh, *drums fingers*. We really need clarity on what the *right thing to do* is. Perhaps mclasen might write up what is expected from apps and im engines in relation to this.
Yes. I have the same problem, i don't really know what the asian users want in the first place, so i took a cue from gedit at the time. If more users want the "commit on cursor move" behaviour, then by all means let's make this work. Of course we'll need to test with a large number of input methods; I remember that some input methods simply did not work wrt reset.
Until we know what we actually want to do here let's see this as an enhancement.
Most korean users want to commit the preedit string when the cursor is moved by mouse. But to commit the preedit string should be implemented on input method side, not the application. The key point is "reset" method. Calling reset method is the application's burden. Application should notify some events to input method via reset method. Whether to commit the preedit string or not is input method's choice. But if the application doesn't call reset method at all, the input method gets no chance to do something with the preedit string. You don't need to call reset method on every cursor move. When the user presses some keys, the key event will be delivered to input method, and input method will update preedit or commit some string. In this case, you don't need to call reset. Input method already knows what's going on. Even when user presses arrow keys, it will be also delivered to input method, so you don't need to call reset. Input method will determine whether to commit the preedit or not by the key arrow key event. But when the user click mouse button on some place in the text edit area, input method doesn't know what's happening. So in this case, you should call reset method. So the reset method should be called when the cursor is moved by mouse clicking. Then the input method should do the rest of things.
>Funny thing is gedit used to move >the preedit around like we do now. When I switched to an Hangul XIM like nabi in Fedora Rawhide, gedit behaved correctly. Given that, I assume it's scim's fault. >Seems there are two opinions on that >behaviour even in Korea. I disagree. This is becoming the biggest barrier on switching to OO for Koreans. Moving the preedit has no point at all in Hangul.
>>Funny thing is gedit used to move the preedit around like we do now. >When I switched to an Hangul XIM like nabi in Fedora Rawhide, gedit behaved >correctly. Given that, I assume it's scim's fault. cmc->modestcode: I have the patch here applied in the fedora OOo variant, and you say you're using fedora rawhide, so is the *fedora* OpenOffice.org behaviour correct or broken ? i.e. I mean... 1) In "vanilla" openoffice.org downloaded from www.openoffice.org this is what happens with hangul scim in calc. scenario a 1.a.1) Single click in A1 ctrl+space to activate hangul scim 1.a.2) qkfrkd 1.a.3) Single click in A2, cursor moves to A2 and an uncommitted glyph follows the insertion point to A2 while the other committed one stays in A1 scenario b 1.b.1) Single click in A1 ctrl+space to activate hangul scim 1.b.2) qkfrkd 1.b.3) Press down arrow, sequence is commmitted to A1. Cursor moves to empty A2 2) And this is what happend in "fedora" openoffice.org in rawhide/F-9 with hangul scim in calc scenario a 2.a.1) Single click in A1 and ctrl+space to activate hangul scim 2.a.2) qkfrkd 2.a.3) Single click in A2, full sequence is committed to A1. Cursor moves to empty A2 2.b.1) Single click in A1 ctrl+space to activate hangul scim 2.b.2) qkfrkd 2.b.3) Press down arrow, sequence is committed to A1. Cursor moves to empty A2 Is there any problems with how we do it in fedora (version 2) ?
>cmc->modestcode: I have the patch here applied in the fedora OOo variant, and >you say you're using fedora rawhide, so is the *fedora* OpenOffice.org behaviour >correct or broken ? i.e. I mean... cmc->For most Korean users, Fedora's behavior is correct.
modestcode->cmc: The scenarios(2.a, 2.b) are what happened to me in rawhide(fc9) too. (FYI, 'qkfrkd' is not a valid Korean word. 'Qkfrkd' is) The odd thing which I'v found: Scenario o.a: o.a.1) Double click in A1 o.a.2) Type 'a' o.a.3) Press down arrow, Cursor remains at A1 is it a variant behaviour in fedora OOo or normal one in vanilla OOo?
modestcode->cmc: Yes, fedora's behaviour is correct as many Koreans said! Yesterday, one user switched from ubuntu to fedora cause of this single bug to void his/her father's complaint.
Yep, it is I that switched from Ubuntu to Fedora only because of this bug. Actually, this bug was quite annoying. Due to this bug, I had to press Spacebar EVERYTIME I finished with a line! (Of course, it is not that serious to me because I do homeworks or assignments mainly in English. However, it is a real problem to my dad; my dad frequently types in Korean and quite annoyed with this problem.) ps. FYI, I'm a high schooler in the States and my parents are all koreans.
o.a.1) Double click in A1 o.a.2) Type 'a' o.a.3) Press down arrow, Cursor remains at A1 Yeah, that's the same for all variants, the difference there is the *Double* click which enters into a cell editing mode, the same thing happens with typing English text. cmc->pl: With my Fedora hat on, part of me is sort of glad that Fedora provides a better experience than Ubuntu ;-) But for the overall OOo is there any known counter-example where this change would have an undesirable effect ? I can't myself see any side-effects like listed in old #i45768#
For your testing, I built the latest development milestone(BEA300_m2) on Ubuntu 8.04 with cmc's patch applied. If you want to test the patch on Ubuntu, you can download my deb packages from the following link. http://openoffice.or.kr/files/BEA300m2_hardy_jeongkyu.tar.gz You can install the packages side-by-side with pre-installed OOo 2.4 on Ubuntu 8.04. However, please note that the above package is vanilla build so that some functions work in different way to Ubuntu(go-oo) build, such as font rendering. To install the packages, $ tar xzvf BEA300m2_hardy_jeongkyu.tar.gz $ cd en-US/DEBS $ sudo dpkg -i *.deb Because there is no desktop-integration provided with this build, you have to run it from command prompt. To run OOo, $ /opt/ooo-dev3/program/soffice Jeongkyu OpenOffice.org Korean NL project lead
I forgot to tell you my build configuration. Here it is ./configure --with-use-shell=bash --with-system-freetype --with-system-mozilla=firefox --with-openldap --with-system-libxslt --with-system-libxml --disable-binfilter .
@pl: I tested cmc's patch with BEA300_m2 on Ubuntu 8.04. And I neither see any side effect of it so far. If you still opposed to the patch, would you give some details so that I can check it again? @cmc: Thanks for your patch. I feel guilty that I could not find your patch even though it has been sitting here for more than a year. :-) Once it is committed, the fix will help many Korean users a lot! Jeongkyu OpenOffice.org Korean NL project lead
cmc->pl: I guess I have to reassign again. The patch here looks popular. If you know of some reproducible side-effects feel free to reassign it back and I'll try and sort them out.
OK, I'll commit that. As my luck runs probably the japanese will come next and ask how I could do that :-)
@pl: Great news, indeed! I hope that Japanese would not hate the change. By the way, is there any method by which we can distinguish the current language of scim so that we can call gtk_im_context_reset() selectively?
Not that I know of. Indeed if you find a method to ask a gtk input context about its language I would be thankful to hear it, since I could then implement GtkSalFrame::GetInputLanguage()
committed in CWS vcl89. I didn't see any problems, but let's wait and see.
please verify in CWS vcl89
looks good for me
seen in master