When using chinese input methods in xfce, they never seem to work in XFFM (but the work everywhere else in XFCE). I have tried both FCITX (which utilises XIM) and also SCIM, which utilises the im_module in gtk2. Attemped in charsets utf8 and gb2312. I'm running xfce 4.0.3, so please close this bug if it has been fixed since.
Additional information: Running Debian Sarge, scim version was 0.99, fcitx version 2.0.1-2, XFCE 4.0.3.
I'm afraid I have no idea what you are talking about (so I don't think it is fixed). If anybody could explain further or provide a patch it would be very helpful.
Asian languages utilise helper programs (called input methods) in order to input characters. They are required to access the lord-knows-how-many ideographs of their respective languages utilising an alpha-numeric keyboard. Most of these utilise the XIM protocol, however there are newer ones that jack into gtk-2 more directly. Fcitx is a chinese input method that utilises XIM, while SCIM is an input method that utilises gtk-2's more intricate protocol (which I've heard is more capable when it comes to scripts that have recombination). One can view the available gtk input methods by right clicking the space where one would usually type. Anywho, these input methods work almost everywhere in xfce, just not in the file manager. One thing it might be is that both of these utilise Ctrl-Space as the activating keystroke, so perhaps this is being blocked? I might try a japanese input method editor (I think they use shift space), and see if that's any more successful.
Indeed, modifier-Space is being sent down a black hole. I've changed that and allowed ctrl-space, alt-space and shift-space to pass through. Could you possibly check out the CVS version to test? You only have to checkout xffm and xfce4-modules to continue using xfce4_0.x. Compile and install xfce4-modules first, then for xffm do a "./configure --enable-oldlibraries". If you cannot do this, please give me some kind of recipe I can follow to see whether the fix is good or not.
OK, the build went fine, I'm using the CVS version now. Modifier space now brings up the input method window (it did not before). However the subsequent letters typed are not registered by the input method, it is as if the input method is not receiving them; so no joy. With the updated CVS version there is of course a new way of renaming things (just click on the filename) which doesn't bring up the traditional input prompt at the top, but allows one to rename the file directly. With this new mode, the input methods tested (fcitx, scim, & kinput2) work flawlessly. There is something about how input is taken there that is different. All input that goes through the input buffer that appears at the top of the window (such as creating files or folders, or doing a goto) is problematic. I must say I like the improvements though, like the new xffrecuent4 and xffrequent. I also like being able to run each function (trash, mountdev, etc) as its own executable, so please keep that going.
Apparently the input problem persists because xffm is trying to do autocompletion (which is probably not what you want). So now I've modified the combo so that autocompletion is turned off whenever the (ctrl|alt|shift)-space is received. That will pass everything through. Autocompletion will remain off until (shift or alt)-backspace is received, if you want to switch back to default behaviour. Please test. You only need to update your CVS version of xfce4-modules (cvs update && make install). Xffm does not need to be updated or rebuilt, just close all xffm instances and restart.
Well done, that appears to have fixed it! A side-effect has occurred though, in that after one uses an input method in the goto box (and then deactivate it with mod-space), pressing enter brings down the drop list, instead of confirming (as it usually would). Of course one can still use the enter button provided at the end of the input buffer, so it isn't really a problem. When this gets patched into the next release it'll make the file manager as i18nalised as the rest of xfce and more likely to be included in asian distros, like hiweed (a chinese debian-based distro with xfce as the default desktop).
The enter key now works as is should (it is not being passed through anymore). You just need to update xfce4-modules for changes to take effect. I've also changed the combination to reenable autocompletion to mod-space. If there are no more problems, this would finish up the fix.
Almost. Goto, rename, and symlink all work perfectly, but new file/directory seems to create nothing. I've found I can create a file with just english, but hybrid english/asian or pure asian does not work. The input window works perfectly, its just that no file/folder is actually created.
There was an error in filename conversion to utf-8. Maybe this was causing the problem. Please check if the the fix solves the problem. You have to update and recompile xffm (nothing with xfce4-modules this time).
Ok, problem solved. While I've tested it with chinese input methods, I cannot test for other input method languages such as japanese or korean. While I think this bug could be closed for chinese users, it may be reopened after feedback from japanese users.
I'm not too happy with the fix, since it turns off autocompletion while in chinese input mode. I don't see any reason why ideograms cannot be autocompleted. If I knew how the ideograms are byte represented the feature should not be difficult to enable. About Japanene/Korean. All that is needed to apply the same fix is to know what key sequence is used to enter/exit the alternate input mode.
For autocomplete usability, GQview's input box is ideal, it has tab completion while one is in the input mode, so one can type one ideogram, press tab and get another (or selection thereof). While the goals of xffm & gqview may differ here (gqview's tab completetion is similar to a bash shell, whereas xffm's is more akin to a web browser's), the unified input method/completetion is already implemented and could be used as reference. As far as my understanding of utf8 goes, it is multibyte, and can range from one byte (like ascii) to up to six bytes depending on the glyph. Here's my reference: http://www-106.ibm.com/developerworks/linux/library/l-linuni.html The difficult thing about japanese is that opposed to chinese (which converts from roman letters straight to ideograms), japanese converts from roman letters to the phonetic symbols of the hirogana, then from the hirogana to kanji. Now as I don't understand japanese, the above may not be entirely correct, but I have noticed the use of both space and enter during character selection (at when least when using the input method: kinput2). I'll see if I can do a little research on korean input (with which I've no experience).
The GQview method sounds good but it might require substancial coding. Alternately, xffm can begin with something simpler where almost all the code is already in place: correct me where I am wrong. Once you enter chinese input mode, you type a series of characters (I suppose A-Z). On exiting chinese input mode, the associated ideogram appears. A fairly easy implementation would create an ideogram history, so that while you are doing the input for the ideogram, the autocompletion will try to complete (in the A-Z format) and if a hit is produced, you just have to exit chinese input mode for the ideogram to appear. If, OTH, partial ideograms are drawn as you input from the keyboard, then the autocompletion would be done only by selecting completed ideograms from the dropdown menu that pops up as you type. Does that sound logical to you?
Not sure on the former, but the latter is more sound. In chinese input mode, you type letters (lets say wo (means I)), a selection box appears, and you select the correct character (as there are usually many homophones) by pressing a number. Or they may select the default by pressing space (but no space is actually inserted). Over time, the input method might move certain characters up in the list (so their number would change) depending on their frequency of use. So if wo is entered, their might be 5 different characters to choose from, and the number of selection will not be constant. Also, there are the words made up of two or more characters. Here a user might type woshi, wo being one character and shi being another. In typing them together the input method may recognise them as the word for bedroom. I think it would be best if the autocompletion is done after the input method returns the utf8 character, based on that utf8 character. Once an input method is activated, the roman letters should no longer be utilised for searching the auto-complete history. This sounds more like the second option if I have understood you correctly (please correct me if I'm wrong).
You are right in that utf8 characters should be used over roman letters for the autocompletion. The problem here is with the hash function. Currently xffm uses g_string_hash(). I'm not sure what kind of results it will give if used with utf-8 characters. Also, my initial perception was a bit simplistic. I had not considered the importance of homophones in Chinese, which convert the autocompletion list from a vector into a matrix. Nonetheless, on examining the code, even with Chinese input after you press return the data should be saved to the history if the command completes correctly. If you do a "go to" where the path has some chinese ideogram, does that entry appear in the combo dropdown list the next time you press "goto" (before doing any keyboard input)? The last successful "goto" path should be at the top of the list.
So far paths with utf8 characters have been saved to the drop-down history, so no problem there. When I go to enter a path with utf8 characters in it, this is what happens: press goto input box appears and gains cursor focus type romanised characters eg /home/adrian/ so far the drop down box is working perfectly type ctrl-space drop down box disappears (and no longer functions) but no input method appears type ctrl-space input method appears and roman letters do not go to the input bar but to the input method (this is normal), and output of input method goes into input bar, usually one ideogram at a time, or perhaps more than one at a time (depending on user operation of IM) press enter xffm goes to the correct path. The problem from my POV, is firstly that ctrl space shouldn't have to be typed twice: the first does nothing but disable autocompletion all together, and the second actually triggers the input method. Ideally you want to reenable auto complete code (is that the g_string_hash()?) and have it listen to the output of the IM.
Doing ctrl-space twice: Actually the first is received by the combo dropdown, not the entry, that's the problem. Of course, this behaviour does not seem natural. It is now fixed in CVS. To test, please note that the --enable-oldlibraries is not working since xfce4-modules is now part of libxfcegui4. This means you must install at least libxfce4util over the old library. Libxfcegui4 can be installed to an alternate prefix so that only xffm will this new version. Once you leave asian input mode, autocompletion should be reenabled. But since you do not exit asian input mode until you finish with all your ideograms, autocompletion is not active. Seems like either one or the other can work at the same time.
OK, that's fixed, now just one ctrl-space is needed to bring up the IM. I'll get around to installing and testing some more diverse input methods, namely japanese and vietnamese (as there are translations for those languages in src/po).
Many apologies for my absence, I've had other things on. I've been mainly using the input engine SCIM for my testing. It can be used for input of japanese, chinese and korean, and it works very well with gtk. It defaults to ctrl-space for activation, and also makes use of ctrl-forwardslash and ctrl-period. All of these keys are fine and work well within the input window xffm supplies. The only strange thing is as follows: In English: When autocompletetion is brings up a previous location, usually when one types letters that do not coincide with that particular history, the suggestion disappears. This functions perfectly in japanese also. The suggested history stays on screen even while english letters are being typed, but as soon as one selects a suitable character (kanji) by pressing space, the kanji is inserted and the suggestion disappears. If however one tries this in chinese or korean, when one selects the character with space, xffm exits immediately, citing signal 11 has been received, exiting. I'm testing this with the SCIM version currently in debian testing (0.9.7-2), but I'm in the process of upgrading it to version 1 to see if the bug persists.
If you could include a gdb backtrace it would be very helpful to determine whether the bug is in xffm or SCIM.
I'm not really familiar with gdb, but I had a go. It does indeed look like its a bug with scim, at least to my untrained eyes it does. If you can confirm this, I'll send a bug report to the SCIM developer, and this bug (XFFM) can be closed. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1084196096 (LWP 4213)] 0x412b3286 in PinyinServerInstance::commit_converted () from /usr/lib/scim-1.0//Server/pinyin.so (gdb) bt #0 0x412b3286 in PinyinServerInstance::commit_converted () from /usr/lib/scim-1.0//Server/pinyin.so #1 0x412b25d8 in PinyinServerInstance::space_hit () from /usr/lib/scim-1.0//Server/pinyin.so #2 0x412af261 in PinyinServerInstance::process_key_event () from /usr/lib/scim-1.0//Server/pinyin.so #3 0x41161314 in gtk_im_context_scim_get_supported_locales () from /usr/lib/gtk-2.0/2.4.0/immodules/im-scim.so #4 0x402dc343 in gtk_im_context_filter_keypress () from /usr/lib/libgtk-x11-2.0.so.0 #5 0x402de946 in gtk_im_multicontext_new () from /usr/lib/libgtk-x11-2.0.so.0 #6 0x402dc343 in gtk_im_context_filter_keypress () from /usr/lib/libgtk-x11-2.0.so.0 #7 0x402962c2 in gtk_entry_get_type () from /usr/lib/libgtk-x11-2.0.so.0 #8 0x402fcb64 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #9 0x405a8fb7 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #10 0x405a8c20 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #11 0x405bc655 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #12 0x405bb9be in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #13 0x405bbee4 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #14 0x403fb427 in gtk_widget_send_expose () from /usr/lib/libgtk-x11-2.0.so.0 #15 0x4040949f in gtk_window_propagate_key_event () from /usr/lib/libgtk-x11-2.0.so.0 #16 0x4040953c in gtk_window_propagate_key_event () from /usr/lib/libgtk-x11-2.0.so.0 #17 0x402fcb64 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #18 0x405a8fb7 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #19 0x405a8c20 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #20 0x405bc655 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #21 0x405bb9be in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #22 0x405bbee4 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #23 0x403fb427 in gtk_widget_send_expose () from /usr/lib/libgtk-x11-2.0.so.0 #24 0x402fb1ae in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #25 0x402f9e56 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #26 0x404f8175 in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0 #27 0x40604932 in g_main_depth () from /usr/lib/libglib-2.0.so.0 #28 0x40605a28 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #29 0x40605d60 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #30 0x406063a3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #31 0x402f9713 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #32 0x08062e54 in main (argc=1, argv=0xbffffb04) at main.c:622
It looks like either a gtk or SCIM bug because the program flow never comes back to xffm once the main gtk loop has entered. But it may be that xffm is withholding something SCIM needs before the chinese input method is begun. To determine this, does the crash happen when: 1- Typing into an autocompletion combo (jump to, for example) 2- Typing directly into a cell (renaming, for example) 3- Typing into an ordinary combo (opening a named book file, with CTRL-B or selecting "Open Book" from the popup menu over the root bookmarks row) If all of the above crash, then it is gtk/SCIM bug. If one of the above does not crash, a bug workaround could be possible.
The crash happens for the first two situations, but not the third. For the third instance, if I'm doing it correctly, while there is an initial suggestion, it isn't hilighted like the first two. The crash occurs in any input mode where there is an initial suggestion hilighted, even, for instance, the cell edit for permissions.
Been away for a long time again. Back at my computer now, using scim 1.0.2-2, and xffm 4.2.1-1, and no crashes occur anymore. Chinese input functions in all input boxes. I've tested all the situations that previously caused hassles, and all seems to be well.