Re: i'm writing a python input module for xcin...

[thhsieh@linux.org.tw]

: Really it's not proper to pop this thingy up, but I sometime   
: find that if I could write something down I could help myself
: clarify it, hence, :) Hope you're not bothered up too much.. ;)

Never mind. :-)) It's welcome to discuss any xcin related issues
here, and I will be very glad that there are people who willing
to discuss it. :-))

: >       gen_inp_init(void *conf, char *objname, xcin_rc_t *xc);
: >       gen_inp_xim_init(void *conf, inpinfo_t *inpinfo);
: > 
: >    Note that the actual format of "void *conf" is completely designed
: >    by you.
: 
: In this case, since I use python, all the IMM local data are in
: python, i.e. managed by python. Hence the C function can get
: its "void *conf" to have only one member that is a "PyObject *"
: which is really a python module handle. (I suppose this could work. ;)
: 
: And you could see that this really "hides" IMM private data from XCIN,
: am i right? ;) Umm, XCIN doesn't touch the internals of "void *conf",
: does it? :)

You are right. XCIN never touch the internals of "void *conf".

You may ask: Why should xcin provide the "void *conf" as the private
data for IM. In fact in IM it can provide its private data for itself,
since these data is not interested by xcin.

The answer, the IM module is not just a "Input Method", but it should
serve as a "template" for different kinds of "Input Method" which 
could use it. For example, the gen_inp module can serve all kinds of
".cin" tables as distinct Input Method: e.g., array30, cj, pinyin ....
etc. So IM module is a template, it provide a definite functionality,
and it can be used by several Input Method which needs these functionality.
But each Input Method using this IM module should have its own private
data structer. This is the reason of this design.

: > 2. The local data structer for each IC client. This kind is 
: >    "inpinfo_t *inpinfo". It contains some items like *inp_cname,
: >    *inp_ename, .... etc. So it also serves the interface of IM module  
: >    and xcin/IC client.
: 
: BTW, *inp_ename and *inp_cname are provided by IMM, XCIN just
: read them, right?

Right.

: >    One perticular item of inpinfo_t is "void *iccf". It can be used
: >    as the private data structer of the IM module. Because sometimes
: >    IM module need a space to keep its private data for each IC client,
: >    so the place mentioned in 1 (the global data structer) is not
: >    enought to use. In this case you can use "void *iccf" in inpinfo_t.
: 
: Here since I give up all IMM private (and IC private) data to be
: managed by python, I don't need to have a "void *iccf", I suppose?

Yes. If you don't need it, just set it to NULL.

: Only I have to read data from python to fill some fields of *inpinfo
: that are needed by XCIN. (and XCIN provides IMM something...)

Yes.

: >  3. area3_len (in xim_init())
: 
: What's that used for, please?

When you start xcin only in "Root" input style, you will see a brown
area in the center of the 2nd line of the xcin window when you switch
to the Chinese input mode. That is the "area3". So this "area3_len"
variable you can provide the length of "area3" window, in unit of
number of English characters.

: > 17. lcch_grouping (the same as 6, if necessary)
: > 18. cch_publish       (in keystroke())
: > 19. cch       (the same as 6).
: 
: All the above are only 'read' by XCIN, i.e. XCIN never write to 'em,
: am I right?

Yes. So if you malloc buffers for the above pointers, at the xim_end()
function you have to free them by yourself. XCIN won't do that for you.

: Argh! ;) I didn't read this in xcin/doc/...
: I should read much more carefully. :)

They are a little old and should be updated. I am doing this.

: > so that "character" will contain one big5 character. Then when you want
: > to sort, compare, search .... the wch_t format character, you can just
: > 
: >       wch_t A, B;
: >       if (A.wch == B.wch) {
: >           ........
: >       }
: >        
: > That is, just do integer compare instead of calling strcmp() ....
:   
: Hmmm, I guess I have to simplify this for Python, and re-construct
: it when returned from python to C, then... :(

Yes. Every IM module do that internally, e.g., bimsphone. bimsphone
treat each Chinese character as Big5 and only Big5, so it use many
compact tricks to handle the characters. And when the characters are
going to send back to XCIN, it should convert them to be wch_t.

The design of wch_t is to ease the future extension up to 4-byte 
encodings like UCS4, or even 3-byte encodings like CCCII.

: Yeah.. I could provide python keystr to be used to search in .cin.
: Other function keys (modifiers etcetra) should be managed within
: C.. maybe pass some config data to python...
: 
: Hmmm... seems that I'm still not decided how much to be passed to
: python and how much to be processed just within C part of IMM... :(
: Should think on this...
: 
: Thank you for your help! :)

A little suggestion :-)) The interface between your IM module & XCIN 
can be written in C. While the .cin table search engine and detailed
IM module functionality can be written in Python, if you like :-)

Unfortunately, I have to say that. The above IM module interface and
character handling system of xcin will be changed in the future,
because they have reached some limitations. But in the xcin-2.5.2
and its updations, they will remain the same. The new design will 
appear in 2.5.3 or later releases. This might cause the IM module
designer some inconvinence or trouble. I am very sorry.


T.H.Hsieh
To Unsubscribe: send mail to majordomo@linux.org.tw
with "unsubscribe xcin" in the body of the message