Bug 203865 - Unexpecting string produced from input sequence using SCIM hangul input method
Unexpecting string produced from input sequence using SCIM hangul input method
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gtk+ (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthias Clasen
David Lawrence
:
Depends On:
Blocks: FC6Desktop
  Show dependency treegraph
 
Reported: 2006-08-24 00:08 EDT by Jong Bae KO
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-01 11:09:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot (42.38 KB, image/png)
2006-08-24 00:08 EDT, Jong Bae KO
no flags Details

  None (edit)
Description Jong Bae KO 2006-08-24 00:08:31 EDT
Description of problem:
Nautilus cannot produce correct Hangul file or folder name.

Version-Release number of selected component (if applicable):
nautilus-2.15.4-4.el5
scim-1.4.4-29.fc6
scim-hangul-0.2.2-6.fc6

How reproducible:
always

Steps to Reproduce:
1. create new file or folder from naultilus
2. rename it
3. type " rhwhdqo"

Actual results:
고조ㅇㅂㅐ

Expected results:
고종배

Additional info:
when I press a right arrow key between "rh","whd" and "qo", I can produce
correct name. eg."rh->whd->qo"
I think it is a buffer problem.
Comment 1 Jong Bae KO 2006-08-24 00:08:31 EDT
Created attachment 134772 [details]
Screenshot
Comment 2 Alexander Larsson 2006-08-24 08:18:32 EDT
Does this not happen in any other application?
Comment 3 Jong Bae KO 2006-08-24 22:19:01 EDT
No. other application works fine in Hangul. I tested with gedit,kedit,oowriter etc
Comment 4 Alexander Larsson 2006-08-25 04:43:25 EDT
This might be a problem with EelEditableLabel which handles the editing in the
icon container. Does it work in a nautilus window that shows the list view?
Comment 5 Jong Bae KO 2006-08-27 19:55:16 EDT
Yes Hangul name is showed in the nautilus. Only Hangul writing problem.
In the terminal, a naming folder or file and viewing are working fine in Hangul.
Comment 6 Akira TAGOH 2006-08-28 02:14:33 EDT
(In reply to comment #4)
> This might be a problem with EelEditableLabel which handles the editing in the
> icon container. Does it work in a nautilus window that shows the list view?
> 

Well, it works fine with creating a new folder. but failed the following steps
with renaming on even the list view:

1. create a folder and just press enter with the default folder name.
2. select Rename from the context menu of the folder that created at step 1.
3. activate scim-hangul with ctrl+space and type rhwhdqo

it looks like an initial cursor position is relevant to this issue. actually it
works if I do reselect the strings like:

2.1. move the cursor at the beginning of line.
2.2. reselect the whole of current folder name with shift+right

or

2.1. move the cursor at the end of line.
2.2. reselect the whole of current folder name with shift+left
Comment 7 Alexander Larsson 2006-08-28 04:11:13 EDT
Very strange. The initial state should be in either of those two states.
Comment 8 Akira TAGOH 2006-08-28 07:22:21 EDT
Interesting thing are, when the selection is replaced by hangul character "rh" -
it happens when typing "rhwh", because "rhw" is still valid hangul character,
but not "rhwh" and IM considers to commit "rh" - normally "wh" is still in the
preedit. but on editing the filename, "wh" is also committed in the front of the
cursor. I mean it looks like "rh"<cursor>"wh" on the editbox.

After the selection is deleted, it looks to me like someone invokes
gtk_im_context_reset(). I haven't looked at the source code yet though.
Comment 9 Matthias Clasen 2006-08-31 15:27:42 EDT
Does 

* Tue Aug 29 2006 Akira TAGOH <tagoh@redhat.com> - 0.2.2-7
- scim-hangul-update-caret.patch: backported from CVS to update the caret.
  (#198721)

have any effect on this ?
Comment 10 Jong Bae KO 2006-09-01 00:45:45 EDT
This bug is getting worse on FC6Test2.

Version-Release number of selected component (if applicable):
nautilus-2.15.92.1-2.fc6
scim-1.4.4-32.fc6
scim-hangul-0.2.2-7.fc6

How reproducible:
always

Steps to Reproduce:
1. create new file or folder from naultilus
2. rename it
3. Activate SCIM-Hangul
4. type " rhwhdqo"

Actual results:
고h조ㅇqㅂㅐ

Expected results:
고종배
Comment 11 Akira TAGOH 2006-09-01 03:40:23 EDT
(In reply to comment #9)
> Does 
> 
> * Tue Aug 29 2006 Akira TAGOH <tagoh@redhat.com> - 0.2.2-7
> - scim-hangul-update-caret.patch: backported from CVS to update the caret.
>   (#198721)
> 
> have any effect on this ?

Well, yes, but this issue is always reproducible in either way no matter what
view is currently used and there are the selection or not then. it may be likely
that reselecting strings just happened to work, because old one and new one
works fine on gedit say.

after upgrading scim-hangul, the behavior seems to be changed. let me describe it:

no changes when the preedit string is committed of course. so it's when you
typed a second 'h'. but right now it looks like <rh>h<wh>[cursor]. and no
preedit strings there. so I'm still suspecting that eel may invokes the
unnecessary gtk_im_context_reset() somewhere.
Comment 12 Alexander Larsson 2006-09-01 05:43:33 EDT
I have a fix that makes eel not reset the context on commit. I'm building it now.
Comment 13 Alexander Larsson 2006-09-01 06:01:14 EDT
The fix is in eel2-2.15.92-4.fc6. Could you verify that it works?
Comment 14 Alexander Larsson 2006-09-01 06:07:36 EDT
Also, a similar bug seems to be in GtkEntry, see:
http://bugzilla.gnome.org/show_bug.cgi?id=353803
Comment 15 Akira TAGOH 2006-09-01 06:33:03 EDT
it works on the icon view. but not on the list view. does it use GtkEntry right?
Comment 16 Alexander Larsson 2006-09-01 06:55:19 EDT
Ah, yes it does. Reassigning this to Gtk+ then.
Comment 17 Matthias Clasen 2006-09-01 11:09:22 EDT
fixed in 2.10.2-6, thanks
Comment 18 Jong Bae KO 2006-09-04 23:37:47 EDT
I tested it, and it works fine.

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