Bug 203865

Created attachment 134772 [details]
Screenshot

Does this not happen in any other application?

No. other application works fine in Hangul. I tested with gedit,kedit,oowriter etc

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?

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.

(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

Very strange. The initial state should be in either of those two states.

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.

Does 

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

have any effect on this ?

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:
고종배

(In reply to comment #9)
> Does 
> 
> * Tue Aug 29 2006 Akira TAGOH <tagoh> - 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.

I have a fix that makes eel not reset the context on commit. I'm building it now.

The fix is in eel2-2.15.92-4.fc6. Could you verify that it works?

Also, a similar bug seems to be in GtkEntry, see:
http://bugzilla.gnome.org/show_bug.cgi?id=353803

it works on the icon view. but not on the list view. does it use GtkEntry right?

Ah, yes it does. Reassigning this to Gtk+ then.

fixed in 2.10.2-6, thanks

I tested it, and it works fine.