Re: [Mlterm-dev-en] Some problem of Big5 cut&paste and XIM(mlterm-cvs)

[<th...@li...>]

Firstly I should say sorry that I haven't joined the mlterm
mailing list:

mlt...@li...

Although I send this mail to this mailing list, but it may be
rejected. So, if someone finds that this mail might be useful,
please help me to deliver it to the mailing list. :-))

: >   1. xcin start before mlterm:
: > 
: >      if I kill xcin under mlterm then mlterm will hang. It
: >      seems that mlterm's XSetICValues() xcin cannot return it,
: >      so mlterm hang there.
: 
:         what I think happens is as follows.
: 
:         If you kill xcin on mlterm , the destroy event happens while you are
: +inputting
:         something from keyboard(that is , while mlterm is receiving keyboard
: +events
:         with *XmbLookupString*) , so mlterm hangs up in XmbLookupString before
: +receiving
:         the destroy event.
: 
:         I tried it on rxvt and the same problem happened.
: 
:         I think this problem cannot be avoided unless XLookupString is always
: +used in
:         receiving us ascii text.
: 
:         But if XLookupString is used like that , it will cause another problem
: +and
:         I don't want to do it.
: 
:         If you want to kill xcin on mlterm , please do it after selecting
: +"unused" as
:         Input Method on mlconfig or pressing keys assigned for XIM_CLOSE (,
: +which stop
:         using XIM).

I have checked out the newest source from the mlterm CVS (date:
2001/12/12 22:30). I tested it with xcin. There is no such problem
described above, i.e., I can safely kill xcin when the mlterm is
the foreground window. Maybe this problem is already fixed :-))

: >   2. no xcin start before mlterm:
: > 
: >      I start xcin after mlterm, but mlterm cannot connect
: >      to xcin even has the proper XMODIFIERS. It seems mlterm
: >      detect no XIM server then forget it even start XIM server
: >      after mlterm start. Tung-Han Hsieh had found same problem
: >      from rxvt-2.7.8.
:         
:         This is my mistake. Please test an attached patch.

The source I checked out from the CVS already contains your patch.
However, my test showed that xcin cannot start after mlterm is running,
otherwise mlterm cannot accept the input from xcin. Even worse, if in
the beginning I start xcin and then mlterm (mlterm can accept the input
from xcin), and then I kill xcin, and restart xcin again, mlterm still
cannot accept the input from xcin.

This should not happen for a standard X11R6 XIM client. I searched
the whole source of mlterm, but I cannot find the function call of
XRegisterIMInstantiateCallback() anywhere. This is the standard
call of X11R6 to provide the ability of the XIM client to connect
to the XIM server once it is available now.

The standard way is like this: the XIM client does not try to open
the connection to the XIM server directly (i.e., call the XOpenIM()).
Instead, it should call XRegisterIMInstantiateCallback() to register
its own XIM connection function. Then it leaves the actually connection
to the Xlib. If Xlib found that there is a valid XIM server running,
it will call the registered connection function provided by the XIM
client and establish the XIM connection. Because Xlib is the first
place to know that if the XIM server is now running or not, so we let
it to decide if this is the time to establish the connection or not.

However, I note that since mlterm has the ability to choose/change
the XIM server in *run time*. So I am not sure that if this is the
reason that you don't want to use XRegisterIMInstantiateCallback()
call in mlterm, or you just missed this point. If you need a simple
example about the usage of XRegisterIMInstantiateCallback(), I could
provide one.

Finally, I should comment that although rxvt-2.7.8 has a similar
problem, as mentioned by Edward G.J. Lee, but the reason is different.
RXVT now completely follows the X11R6 XIM standard, i.e., it calls
XRegisterIMInstantiateCallback(). The reason that xcin should start
before rxvt is that otherwise, rxvt will silently turn off any possibility
to connect to any XIM servers. It tries to search and connect to any
valid XIM server when it starts. If it falses, then turn off it. I my
point of view, I don't think this is necessary to "try to search and
connect". I think just leave this job to Xlib then everything is OK.


Best Regards,

T.H.Hsieh