Bug 198721 - cursoring on the left during input with scim-bridge, on the right with scim
Summary: cursoring on the left during input with scim-bridge, on the right with scim
Alias: None
Product: Fedora
Classification: Fedora
Component: scim-hangul
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact:
Keywords: i18n
Depends On:
Blocks: SCIM
TreeView+ depends on / blocked
Reported: 2006-07-13 04:53 UTC by Lawrence Lim
Modified: 2014-03-26 00:53 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2006-08-31 14:38:35 UTC

Attachments (Terms of Use)
cursor position with GTK_IM_MODULE=scim (83.79 KB, image/png)
2006-07-14 05:16 UTC, Lawrence Lim
no flags Details
cursor position with GTK_IM_MODULE=scim-bridge (82.75 KB, image/png)
2006-07-14 05:17 UTC, Lawrence Lim
no flags Details

Description Lawrence Lim 2006-07-13 04:53:05 UTC
Description of problem:
Was wondering if the blinking cursor should be on the right hand side of the
pre-edit buffer during input in oowriter. At the moment, its on the left, looks
a bit strange. On gedit, there's no blinking cursor.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.start oowriter and activate scim
2.choose hangul and start input
Actual results:
blinking cursor on the left of pre-edit buffer

Expected results:
should be on the right or no blink?

Additional info:

Comment 1 Akira TAGOH 2006-07-13 05:19:13 UTC
Not really - There are no APIs to manage the application cursor. probably I
should reassign this to OOo because preedit handling on the application really
depends on that application. FWIW you can see a similar behavior with scim-anthy
on during the conversion, though.

Comment 2 Caolan McNamara 2006-07-13 09:47:53 UTC
If I activate scim, choose hangul and then

in writer press q I get a hangul symbol, highlighted in blue and a black cursor
blinking to the right of the symbol

in gedit press q I get a hangul symbol, highlighted in black and a black cursor
blinking to the right of the symbol

So both seem to behave the same for me except for the highlighting colour, which
in gtk is the same as the cursor colour making it not so obvious.

Perhaps there's a required locale setting ?

Comment 3 Akira TAGOH 2006-07-14 03:40:47 UTC
same behavior for me. this may be not a bug. Lawrence?

Comment 4 Lawrence Lim 2006-07-14 05:14:49 UTC
RE: Comment #1:
Tagoh-san, yes you are right, the cursoring has similair behaviour to Anthy when
the conversion is on. However, I find something very interesting today.

The blinking cursor is determine by the GTK_IM_MODULE, ie. the behaviour differs
between scim and scim-bridge. What was reported was default scim-bridge. Hence,
I think it shuold be assign to scim-bridge for further investigation?

Please see screenshot.

Comment 5 Lawrence Lim 2006-07-14 05:16:21 UTC
Created attachment 132407 [details]
cursor position with GTK_IM_MODULE=scim

GTK_IM_MODULE=scim oowriter

Comment 6 Lawrence Lim 2006-07-14 05:17:26 UTC
Created attachment 132408 [details]
cursor position with GTK_IM_MODULE=scim-bridge

GTK_IM_MODULE=scim-bridge oowriter

Comment 7 Caolan McNamara 2006-07-14 08:43:50 UTC
Ok, if I change the font color of gedit to be 0xFF0000 (bright red), and repeat
the above tests under scim-bridge I find that oowriter and gedit also both
behave the same under scim-bridge, it's just harder to see the cursor in gedit
with the default colours. So we're consistent here in oowriter with the rest of
the the gtk apps in relation to cursor positioning, both on the left with
scim-bridge, and both on the right with scim.

I presume that this is a "scim-bridge-gtkimm" issue.

Comment 8 Ryo Dairiki 2006-07-14 11:46:04 UTC
I've been fixed this issue, but I cannot login cvs server for some reason.
I'll notice you as soon as I upload it.

Comment 9 Ryo Dairiki 2006-07-15 06:19:32 UTC
Fixed on the CVS latest.

Comment 10 Ryo Dairiki 2006-07-21 01:58:14 UTC
I've found this causes an annoying cursor movements for Japanese. :(
To fix both problems, we need to apply patches on scim, scim-gtkimm, and scim-hangl.
(Don't worry, all of the patches are already written)

now I'm discussing at scim-dev-list if it's correct way to fix this problem.

Comment 11 Jens Petersen 2006-07-26 06:05:47 UTC
Fixed in current scim-bridge according to my testing.

Comment 12 Jens Petersen 2006-07-26 11:33:40 UTC
Sorry I take back the last comment - seems as Dairiki-san also said
in comment 10 this is not changed yet.  However this only seems to
affect scim-hangul and I don't see that the new behaviour is really
worse than the old one.

Comment 14 Jens Petersen 2006-08-28 08:59:33 UTC
Actually Krisna applied the following patch for this to scim-hangul in cvs,
probably worth testing.

* update preedit caret when updating preedit string

Index: scim_hangul_imengine.cpp
RCS file: /cvsroot/scim/scim-hangul/src/scim_hangul_imengine.cpp,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -d -r1.10 -r1.11
*** scim_hangul_imengine.cpp	24 Jul 2006 13:42:15 -0000	1.10
--- scim_hangul_imengine.cpp	24 Jul 2006 15:03:57 -0000	1.11
*** 638,641 ****
--- 638,642 ----
          show_preedit_string ();
          update_preedit_string (wstr, attrs);
+         update_preedit_caret (wstr.length());
      } else {
          hide_preedit_string ();

Comment 15 Jens Petersen 2006-08-29 08:51:29 UTC
Above patch does not seem to fix the problem for me with scim-bridge-0.4.1.

Dairiki-san, is some patch also needed on scim itself (other than scim-gtkimm)?

Comment 16 Ryo Dairiki 2006-08-29 10:23:34 UTC
Sounds strange.
I'm now using the same patch on scim-hangul-0.2.2, with scim-bridge-0.4.2-rc1.
It works fine; The cursor always shows on the right of the preedit string.
I've rollback on 0.4.1 but nothing changed.

Did you really patch on it?
Please confirm that again.

Comment 17 Jens Petersen 2006-08-29 10:37:03 UTC
Hmm, sorry after rebooting my test machine it works for me too.  Strange.

Thanks for the patch. :)

Comment 18 Akira TAGOH 2006-08-29 12:33:39 UTC
Ok, should be fixed in 0.2.2-7.fc6.

Comment 19 Satyabrata Maitra 2006-08-31 14:38:35 UTC
this problem is now fixed.

Component Version tested :


Arch : i386 - rawhide

Note You need to log in before you can comment on or make changes to this bug.