of encodings the IMserver supports. XIM client will be notified of thisargument immediately after it makes a connection with the IMserver.   The IMEncdoingList argument is used to specify which encodings can beused to exchange localized-text between the IMserver and XIM clients.   If it's left unspecified, only "COMPOUND_TEXT" encoding will be usedas a fallback default.   XIMEncodings structure is defined by IMdkit as follows:typedef char *XIMEncoding;typedef struct {    unsigned short count_encodings;    XIMEncoding *supported_encodings;} XIMEncodings;2.11.   IMFilterEventMask   The IMFilterEventMask argument, of type long, specifies the eventswhich should be filtered by the IMserver during the preeditting is ongoing.   If it's left unspecified, KeyPressMask (1L<<0) will be fallbackdefault.2.12.   IMProtocolDepend   The IMProtocolDepend argument is used to specify special IM valuesfor each IMProtocol model, if any. This attribute is passed toIMOpenIM, IMSetIMValues or IMGetIMValues as a nested variable lengthlist generated with XVaCreateNestedList(). At this release, thenames in the IMProtocolDepend list are defined only for R5 Ximp model,as below.2.12.1.   R5 Ximp dependent IM ValuesXIMPVersion   The XIMPVersion argument, of type string, specifies the version of R5Ximp model.	value		meaning	---------------------------------------------	"3.5"		supports Ximp version 3.5 model	"4.0"		supports Ximp version 4.0 modelXIMPType   The XIMPVersion argument, pointer to a list of type unsigned long,specifies a list of bitmask combinations, each of which indicates theevent flow model your IMserver supports. All possible values to beappeared in the list are defined as follows.(*)(*) Refer to "Protocol Specification for the Distributes Input System onthe X Window System, Version 11", which contains in X11R5 contribuion.  XIMP_BE_TYPE1	back-end type, which IMlibrary recognizes registered keys and	notifies a server to start processing key events.  XIMP_FE_TYPE1	front-end type, which IMlibrary recognizes registered keys and	notifies a server to start processing key events.  XIMP_BE_TYPE2	back-end type, which IMlibrary does not recognize any registered	keys and. IMserver will always the first to process key events.  XIMP_FE_TYPE2	front-end type, which IMlibrary does not recognize any	registered keys and. IMserver will always the first to process	key events.  XIMP_FE_TYPE3	front-end type, which key events are always passed to both	IMserver and IMlibrary. Both of them recognize registered keys.  XIMP_SYNC_BE_TYPE1	XIMP_BE_TYPE1 & KeyPress is transfered synchronously.  XIMP_SYNC_BE_TYPE2	XIMP_BE_TYPE2 & KeyPress is transfered synchronously.XIMPExtension   The XIMPExtension argument is used to set/unset the pre-registeredextensions to be valid. This list is also a nested variable length listgenerated with XVaCreateNestedList(). At this release, thepre-registered extensins appeared in the XIMPExtension list are definedas below.  XIMPExtStatusWin	If it is appeared in the list, the XNExtXimp_StatusWindow input	context	attribute is valid to set the status window. The	attribute value	isn't evaluated.  XIMPExtBackFront	If it is appeared in the list, the XNExtXimp_Backfront input	context is valid to select the front-end method or back-end	method. The attribute value isn't evaluated.  XIMPExtConversion	If it is appeared in the list, the XNExtXimp_Conversion input	context is valid to set the input mode. The attribute value	isn't evaluated.3.   X IMProtocol Strucutures   For each X IMProtocol input, a corresponding structure is defined inpublic header files of IMdkit. <X11/Ximd/Xi18n.h> defines all IMProtocolstructures for R6 standard IMProtocol model, and <X11/Ximd/Ximp.h>defines all for R5 Ximp model.3.1.   R6 IMProtocol3.1.1. IMProtocol union data structure   In R6 standard IMProtocol model, all the event structures have thefollowing common members:typedef struct {    int major_code;	/* major code of last IMProtocol */    int minor_code;	/* minor code of last IMProtocol */    CARD16 connect_id;	/* client connection ID */} IMAnyStruct;   The major_code and minor_code specify the IMProtocol type constantname that uniquely identifies itself.   In addition to the individual structures declared for each IMProtocoltype, the IMProtocol structure is a union of the individual structuresdeclared for each IMProtocol type. Depending on the type, you shouldaccess members of each IMProtocol by using the IMProtocol union.typedef union _IMProtocol {    int	major_code;    IMAnyStruct any;    IMConnectStruct imconnect;    IMDisConnectStruct imdisconnect;    IMOpenStruct imopen;    IMCloseStruct imclose;    IMQueryExtensionStruct queryext;    IMGetIMValuesStruct getim;    IMEncodingNegotiationStruct encodingnego;    IMExtSetEventMaskStruct extsetevent;    IMExtForwardKeyEventStruct extforward;    IMExtMoveStruct extmove;    IMSetEventMaskStruct setevent;    IMChangeICStruct changeic;    IMDestroyICStruct destroyic;    IMResetICStruct resetic;    IMChangeFocusStruct changefocus;    IMCommitStruct commitstring;    IMForwardEventStruct forwardevent;    IMTriggerNotifyStruct triggernotify;    IMErrorStruct imerror;    IMGeometryCBStruct geometry_callback;    IMPreeditCBStruct preedit_callback;    IMStatusCBStruct status_callback;    long pad[32];} IMProtocol;   The first two entries of any IMProtocol structure are always themajor_code and minor_code members, which specifies the IMProtocol type.The third member is the connect_id member, just provided for IMdkitinternal use to distinguish a client from each other.3.1.2. Protocol Processing   Some of IMProtocol requests sent by the IMlibrary are processedinternally by IMdkit without passing them to your IMservers, becauseIMdkit can determin the answer to such IMProtocol requests only byusing the IMValues which you have set in the XIMS structure.   At this release, the following four IMProtocol requests is processedin IMdkit itself, and wouldn't forward to your IMserver:	o XIM_CONNECT		-> XIM_CONNECT_REPLY	o XIM_DISCONNECT	-> XIM_DISCONNECT_REPLY	o XIM_QUERY_EXTENSION	-> XIM_QUERY_EXTENSION_REPLY	o XIM_GET_IM_VALUES	-> XIM_GET_IM_VALUES_REPLY   So, you don't have to know the details of the correspondingIMProtocol structures for these IMProtocol requests.   On the other hand, you will need to deal with the following requestsfor yourselves:	o XIM_OPEN	o XIM_CLOSE	o XIM_SET_IC_FOCUS and XIM_UNSET_IC_FOCUS	o XIM_DESTROY_IC	o XIM_RESET_IC	o XIM_CREATE_IC, XIM_SET_IC_VALUES and XIM_GET_IC_VALUES	o XIM_TRIGGER_NOTIFY	o XIM_FORWARD_EVENT   However, you don't have to receive any raw packets, but can receivethe corresponding IMProtocol structures in your IMProtocolHandlercallback function. Further, you don't have to send a reply foryourselves, but IMdkit will send a reply soon after yourIMProtocolHandler returns. If your IMProtocolHandler returns True,IMdkit will send the proper reply to the previous request, and if itreturns False, IMdkit will send XIM_ERROR reply to the XIM client.   The following IMProtocol structures are what you will actuallyreceive instead of IMProtocol requests in your IMProtocolHandlerfunction.IMOpenStruct------------   The IMOpenStruct structure is used for XIM_OPEN and XIM_OPEN_REPLYrequests. The structure contains:typedef struct {    int length;    char *name;} XIMStr;typedef struct {    int major_code;    int minor_code;    CARD16 connect_id;    XIMStr lang;} IMOpenStruct;   Your IMserver should check lang field to know which language serviceis required by the new client, which is identified with connect_idmember.IMCloseStruct-------------   The IMCloseStruct structure is used for XIM_CLOSE and XIM_CLOSE_REPLYrequests. The structure contains:typedef struct {    int		major_code;    int		minor_code;    CARD16	connect_id;} IMCloseStruct;   Your IMserver should check connect_id member to know which inputmethod connection should be closed.IMChangeFocusStruct-------------------   The IMChangeFocusStruct structure is used for XIM_SET_IC_FOCUS andXIM_UNSET_IC_FOCUS requests. The structure contains:typedef struct {    int major_code;    int minor_code;    CARD16 connect_id;    CARD16 icid;	/* input context ID to change focus */} IMChangeFocusStruct;   Your IMserver should check icid member to know which input contextshould be focusd or unfocusd.IMDestroyICStruct-----------------   The IMDestroyICStruct structure is used for XIM_DESTROY_IC andrequest. The structure contains:typedef struct {    int major_code;    int minor_code;    CARD16 connect_id;    CARD16 icid;	/* input context ID to destroy */} IMDestroyICStruct;   Your IMserver should check icid member to know which input contextshould be destroyed.IMResetICStruct---------------   The IMResetICStruct structure is used for XIM_RESET_IC request. Thestructure contains:typedef struct {    int major_code;    int minor_code;    CARD16 connect_id;    CARD16 icid;	/* input context ID to reset */    CARD16 length;	/* length of committed string below */    char *commit_string; /* string to commit to XIM client */} IMResetICStruct;   Your IMserver should check icid member to know which input contextshould be reset.IMChangeICStruct----------------   The IMChangeICStruct structure is used for XIM_CREATE_IC,XIM_SET_IC_VALUES and XIM_GET_IC_VALUES requests. The structurescontain:/* *  value type for IC defined in XimProto.h */#define	XimType_SeparatorOfNestedList	 0#define	XimType_CARD8			 1#define	XimType_CARD16			 2#define	XimType_CARD32			 3#define	XimType_STRING8			 4#define	XimType_Window			 5#define	XimType_XIMStyles		10#define	XimType_XRectangle		11#define	XimType_XPoint			12#define XimType_XFontSet		13#define XimType_XIMOptions		14#define XimType_XIMHotKeyTriggers	15#define XimType_XIMHotKeyState		16#define XimType_XIMStringConversion	17#define	XimType_NEST			0x7ffftypedef struct {    int attribute_id;	/* ID for this IC */    CARD16 name_length;	/* length of IC name below */    char *name;		/* IC name */    int value_length;	/* length of IC value below */    void *value;	/* IC value */    int type;		/* value type for IC, see above */} XICAttribute;typedef struct {    int major_code;    int minor_code;    CARD16 connect_id;    CARD16 icid;	/* input context ID:	   for each CREATE, different ID is expected to be returned.	   for each SET, it shows the ID to set.	   for each GET, it shows the ID to get.	 */    CARD16 preedit_attr_num;	/* number of preedit_attr list below */    CARD16 status_attr_num;	/* number of preedit_attr list below */    CARD16 ic_attr_num;		/* number of ic_attr list below */    XICAttribute *preedit_attr;	/* IC values for preedit attribute */    XICAttribute *status_attr;	/* IC values for status attribute */    XICAttribute *ic_attr;	/* IC values for other attributes */} IMChangeICStruct;   When XIM_SET_IC_VALUES or XIM_GET_IC_VALUES, your IMserver shouldcheck icid member to know which input context should be specified. WhenXIM_CREATE_IC, your IMserver should set icid member to identify theinput context newly created. IMTriggerNotifyStruct---------------------   The IMTriggerNotifyStruct structure is used for XIM_TRIGGER_NOTIFYrequest. The structure contains:typedef struct {    int major_code;    int minor_code;    CARD16 connect_id;    CARD16 icid;    CARD32 flag;    CARD32 key_index;    CARD32 event_mask;} IMTriggerNotifyStruct;IMForwardEventStruct--------------------   The IMForwardEventStruct structure is used for XIM_FORWARD_EVENTrequest. The structure contains:typedef struct {    int major_code;    int minor_code;    CARD16 connect_id;    CARD16 icid;	/* input context ID */    BITMASK16 sync_bit;	/* precessed synchronously or not */    CARD16 serial_number;    XEvent event;	/* X event to be filtered */} IMForwardEventStruct;3.2.   R5 Ximp IMProtocol3.2.1. XIMProtocol union data structure   In R5 Ximp IMProtocol model, all the event structures have thefollowing common members:typedef struct {    INT32 type;		/* message type */    CARD32 icid;	/* input context ID */    Window focus_win;	/* focus window */    long fwin_sel_mask; /* focus window select-mask */    CARD32 ximp_type_mask; /* Ximp event flow type */    Window client_win;	/* client window */} XIMPAnyStruct;   The type member specifies the Ximp IMProtocol type constant name thatuniquely identies itself.   In addition to the individual structures declared for each XimpXIMProtocol type, the Ximp IMProtocol structure is a union of theindividual structures declared for each Ximp IMProtocol type. Dependingon the type, you should access members of each Ximp IMProtocol by usingthe XIMProtocol union.typedef union _IMPProtocol {    int				type;    XIMPAnyStruct		any;    XIMPKeyEventStruct		keyevent;    XIMPICValuesStruct		create;    XIMPICValuesStruct		setvalue;    XIMPICValuesStruct		getvalue;    XIMPAnyStruct		destroy;    XIMPAnyStruct		regkey;    XIMPAnyStruct		setfocus;    XIMPAnyStruct		unsetfocus;    XIMPClientWindowStruct	clientwin;    XIMPFocusWindowStruct	focuswin;    XIMPMoveStruct		move;    XIMPEventMaskNotifyStruct	evmasknotify;    XIMPExtensionStruct		extension;    XIMPReadPropStruct		readprop;    XIMPResetStruct		reset;    XIMPCommitStringStruct	commitstring;    XIMPErrorStruct		error;    XIMPAnyStruct		geometry_cb;    XIMPPreeditCBStruct		preedit_cb;    XIMPStatusCBStruct		status_cb;    long			pad[24];} IMPProtocol;   The first entry of any XIMProtocol structure is always thetype member, which specifies the Ximp IMProtocol type.4.   Writing IMserversWhen writing an IMserver that uses the IMdkit, you should make sure thatyour IMserver performs the following:   1. Include <X11/Xlib.h> in your IMserver programs.   2. Include <X11/Ximd/IMdkit.h>. This header file defines all the   necessary data types and IMdkit functions that you need to use.   3. Include <X11/Ximd/Xi18n.h> for R6 standard IMProtocol, or   <X11/Ximd/Ximp.h> for R5 Ximp IMProtocol, respectively.   4. Call the IMOpenIM function with all the necessary IMValues to   initialize the connection. The names of each IMValues have a global   symbol that begins with IM to help catch spelling errors. For   example, IMModifiers is defined for the XIMProtocol model, and   IMLocale is defined for the locale resource. For further information,   see "Section 1.1 Open IM Service" and Section 2 "IMValues"   5. To set additional IMValues or override the existing IMValues you   set by IMOpenIM, use IMSetIMValues. You can also use IMGetIMValues to   look up at existing IMValues. Note that some of IMValues must be set   at the IM service creation time, and never be changed by   IMSetIMValues.   6. You must set the IMProtocol callback routine by the   IMProtocolHandler argument with IMOpenIM or IMSetIMValues functions.   This callback is called whenever the IMProtocol is delivered by XIM   clients.   7. Now you should select all the necessary X events for your windows   with XSelectInput function, and map the windows with XMapWindow   function, then sit in a loop processing events as follows.    for (;;) {	XEvent event;	XNextEvent(your_display, &event);	if (XFilterEvent(&event, NULL) == True)	  continue;	YourXEventHandler(&event);    }   Here, all the IMProtocols you need are passed to your IMProtocol   callback routine by X Filtering mechanism of XFilterEvent function,   and all unfiltered X events you want are passed to YourXEventHandler   function above.   8. Link your IMserver with libXimd (the IMdkit library) and libX11   (the core X library). The following provides a sample command line:	cc -o sampleIM sampleIM.c -lXimd -lX11