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.
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.