! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Input methods in XFFM
Status:
RESOLVED: FIXED

Comments

Description adrian1342 2004-07-17 00:30:39 CEST
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.
Comment 1 adrian1342 2004-07-17 00:30:41 CEST
Additional information:

Running Debian Sarge, scim version was 0.99, fcitx version 2.0.1-2, XFCE 4.0.3.
Comment 2 edscott editbugs 2004-07-17 01:05:43 CEST
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.
Comment 3 adrian1342 2004-07-17 02:56:29 CEST
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.
Comment 4 edscott editbugs 2004-07-17 14:59:52 CEST
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.
Comment 5 adrian1342 2004-07-18 11:09:41 CEST
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.
Comment 6 edscott editbugs 2004-07-18 13:36:56 CEST
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.
Comment 7 adrian1342 2004-07-18 23:21:44 CEST
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).
Comment 8 edscott editbugs 2004-07-19 03:07:09 CEST
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.
Comment 9 adrian1342 2004-07-19 06:27:10 CEST
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.
Comment 10 edscott editbugs 2004-07-19 17:32:58 CEST
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).
Comment 11 adrian1342 2004-07-20 09:06:56 CEST
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.
Comment 12 edscott editbugs 2004-07-20 19:27:00 CEST
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.
Comment 13 adrian1342 2004-07-20 22:50:15 CEST
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).
Comment 14 edscott editbugs 2004-07-21 01:00:04 CEST
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?
Comment 15 adrian1342 2004-07-21 22:01:14 CEST
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).
Comment 16 edscott editbugs 2004-07-22 00:10:26 CEST
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.
Comment 17 adrian1342 2004-07-25 06:18:39 CEST
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.
Comment 18 edscott editbugs 2004-07-26 03:01:11 CEST
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.
Comment 19 adrian1342 2004-07-26 08:31:48 CEST
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).
Comment 20 adrian1342 2004-10-07 04:22:11 CEST
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.
Comment 21 edscott editbugs 2004-10-07 13:16:08 CEST
If you could include a gdb backtrace it would be very helpful to determine
whether the bug is in xffm or SCIM.
Comment 22 adrian1342 2004-10-10 03:33:02 CEST
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
Comment 23 edscott editbugs 2004-10-10 14:46:52 CEST
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.

Comment 24 adrian1342 2004-10-15 12:54:12 CEST
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.
Comment 25 adrian1342 2005-06-24 11:22:32 CEST
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.

Bug #261

Reported by:
adrian1342
Reported on: 2004-07-17
Last modified on: 2009-07-14

People

Assignee:
edscott
CC List:
0 users

Version

Version:
unspecified

Attachments

Additional information