Red Hat Bugzilla – Bug 207062
pre-editing state problem on Hangul in nautilus
Last modified: 2008-05-06 20:51:49 EDT
Description of problem: When you type Hangul, Last pre-editing letter doesn't included in a file name or folder name with left-click action.(It is working with Enter key) Version-Release number of selected component (if applicable): gtk+-1.2.10-55.fc6 nautilus-2.16.0-3.fc6 How reproducible: always Steps to Reproduce: 1. open nautilus and run scim-hangul 2. activate scim- hangul 3. make new folder or file 4. type "gksrmf" in Korean "한글" 5. click the left-click on the window Actual results: 한 Expected results: 한글 Additional info: I tested with oowriter. They save the pre-edit state letter on file name as well when I save the file.
The Component of bug 207602 is wrong. nautilus doens't use gtk+ package, and gtk+ package is extras. And this problme doesn't happen in my linux box. gtk2-2.10.3-6.fc6 eel2-2.16.0-1.fc6 nautilus-2.16.0-3.fc6 scim-hangul-0.2.2-7.fc6
Jong Bae, is this happening in a n icon view, or a list view ?
Hi Matthias This bug happen in both, but if you type Hangul and then click on white place (empty space) in the list view on natilus, the pre-editing state is stopped so It works fine. However, when you type Hangul, and then click other folders or files, it has the same problem. Main problem is pre-editing state.
Sorry, my mistake. Clicking left button on preedit state,preedit -> commit works well in a icon view ,but bug 207062 happens in a list view.
Jong Bae, do you see this problem with other applications too, e.g. gedit ?
No. gedit is fine. I tested with gedit, and It contained pre-edit state's letter as well in both file name and document.
Ok, then it is probably an eeleditablelabel problem
The bug is produced in gnome desktop as well
"Clicking left button on preedit state,preedit -> commit works well in a icon view, but bug 207062 happens in a list view." Did you actually mean this, or did you mean the bug happens in the icon view?
He means that it happened in the list view only. However, In my test, It happened both(list view and icon view).
I also tested. this happens on both. so I guess there are still similar issue like Bug#203865?
Yes. still pre-editing state is not stable in nautilus.
If it happens on both then it could be a gtk+ issue too. The edit widget for icon views is EelEditableLabel, but for the tree/list view we use a normal GtkTreeView + GtkEntry.
I was unable to reproduce this in the icon view. However, i was able to reproduce it in the list view and in the "Tree View -> Editable Cells" example gtk-demo, so this seems to be a Tree View bug. When the editable widget is removed and its value saved we don't flush the preedit state (or whatever needs doing).
there is no way to "flush preedit state" in the GtkIMContext api. the user is responsible for committing all outstanding preedit state before dismissing the editable widget.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp