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

[zw@zhaoway.com]

On Thu, Jul 27, 2000 at 09:43:14PM +0800, thhsieh@linux.org.tw wrote:
> : Sorry I use GB2312 below... I should dig up my mail sub-system
> : or better setup my zh_TW.Big locale lah... anyway...

[snip]

> Hello, I see the Big5 in your mail. Are you sure you sent it in GB2312? :-))
> Any way, I reply in English, and hope that this way is convinent to you :-))

I can read Big5, :) that I cannot input Big5, haven't got time
to dig on that... :( Anyway, I happened to have a little script
from zh-autoconvert from Saka(?) so I just piped my email drafts
thru it... lazy to change the letter then... :)

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.. ;)

[snip]

> Sorry, I cannot understand your words very well. But from the point of 
> view of the IM module, it will have 2 kinds of data structer:
> 
> 1. The global data structer for this IM module. It can be used to
>    keep the private data of this IM module, and it is global to
>    every IC client (note that any IM module should serve many different
>    IC client). This data structer is passed into the IM module interface
>    function as "void *conf" pointer. For example,
> 
> 	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? :)

> 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?

>    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?

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

> :  小弟現在所頭疼的是, 不是特別清楚 inpinfo 中哪一些是
> : 應該 pep_inp (gen_inp的地位) 來寫的, 哪一些是 XCIN 來寫的,
> : (protocol between {gen,pep}_inp and XCIN? ;)
> 
> You should provide:
> 
>  1. inp_cname	(in xim_init())
>  2. inp_ename	(in xim_init())
>  3. area3_len	(in xim_init())

What's that used for, please?

>  4. iccf	(in xim_init(), but only when you really need it)
>  5. guimode	(in xim_init() & keystroke(), you may need to update it
> 		 during the input from users)
>  6. s_keystroke (in xim_init(), you should prepare buffer to it,
> 		 and in keystroke(), you may need to update it)
>  7. suggest_skeystroke (the same as 6)
>  8. n_selkey	(in xim_init())
>  9. s_selkey	(in xim_init())
> 10. n_mcch	(in keystroke())
> 11. mcch	(the same as 6)
> 12. mcch_grouping (the same as 6)
> 13. mcch_pgstate (in keystroke())
> 14. n_lcch	(in keystroke(), if necessary)
> 15. lcch	(the same as 6, if necessary)
> 16. edit_pos	(in keystroke(), if necessary)
> 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?

> And the information from xcin to IM module (provided by xcin) are:
> 
> 1. imid (you should not modify this)
> 2. zh_ascii
> 3. xcin_wlen

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

mmm....

> : 還有 wch_t 是怎麼一回事啊? 因為這個和 Python 混起來,
> : 搞的我很頭疼啊... (maybe I shall read more documents, dizzy %-(
> 
> It is the unified format for each character:
> 
> typedef union { 
>     unsigned char s[WCH_SIZE];
>     wchar_t wch;
> } wch_t;
> 
> For example, each Chinese character contains 2-byte, so you can do this:
> 
> 	wch_t character;
> 	character.wch = (wchar_t)0;	/* initialize */
> 	strncpy(character.s, "您", WCH_SIZE);
> 
> 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... :(

> : 還有 ?_selkey, 因為小弟隻是用 pinyin.cin 所以不大清楚
> : 這有什麼用呢? 為什麼要由 .cin 來定義 ?_selkey 呢?
> 
> Some input method use "1234567890" to select duplicated characters,
> but some use "asdfgjkl;", or use "'[]-=" .... etc. So this depends
> on the detailed definition of the input method.

I see. Thanks.

> : 此外,我可不可以把 keyinfo 簡化成 ascii string 傳給 Python
> : (.cin) 呢? 其它的功能應該是由 pep_inp_keystroke() 自己處理的?
> 
> Yes. keyinfo_t contains the completed information of user's key-press.
> The keyinfo_t->keystr is the ASCII representation of a key. But sometimes
> the user may press function keys like Ctrl, Alt, F1, .... etc. If your
> IM module need these keys to do some perticular actions, you need to
> exam keyinfo_t->keysys or keyinfo_t->keystate, too.

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! :)


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