1. 1 Proposal of Next Generation Input Method framework IM-BUS project James Su

2. 2 Profile James Su  Maintainer of SCIM project (http://www.scim-im.org)  Member of NEA-OSS WG3/SWG1 input method standard working group  Engineer of Google Linux Client Team. NEA-OSS WG3/SWG1  A working group dedicates to develop a new input method SPI specification for Linux.  IM-BUS is the infrastructure project of the SPI.

3. 3 Members of NEA-OSS WG3/SWG1 Chairman:  Roger So (Sun Wah Linux, Debian developer) Secretary:  Hiroshi Miura (NTT Data Corp. and IPA OSS Center) Technical members:  Hideki Hiura (Justsystem, Inc. Creator of XIM and IIIMF)  Choe Hwanjin (Hannsoft. Developer of Hangul input method)  James Su (Maintainer of SCIM project)  Many others.

4. 4 Current situation Many different Input Method protocols and frameworks for Input Method developers.  XIM – Only available in X Window, full of problems.  IIIMF – Successor of XIM, though not so successful.  SCIM – Used by many distros, has many known issues.  UIM – Mainly focus on Japanese and embedded os. Many different APIs for application developers  XIM / GTK immodule / QT immodule /... Many limitations, problems, bugs...

5. 5 New approach: IM-BUS Inspired from the design of D-BUS Written in pure C to avoid compatibility issues Fully object oriented Extensible Compatible with XKB Dynamic / modulized Platform and GUI independent Support almost all requirements of existing Input Method Engines and applications

6. 6 Overall architecture of IM-BUS IM- BUS Daem on App 1 GUI modul e Other modul e IME modul e 1 IME modul e 2 App 2 One IM-BUS Daemon per desktop session

7. 7 Technical details (1) Overall architecture  IM-BUS daemon: Forward events between components Maintain states and informations of components  IM-BUS components: Include Input method Engines, Applications, UI modules, etc. Communicate with each other by sending/receiving events via IM-BUS daemon  Communication between IM-BUS daemon and components are asynchronous by using Unix domain socket

8. 8 Technical details (2) Events and Event roles of a component  Events are the basic communication elements between components, for example: Create/destroy Input Context events Key press/release events Focus In/Out events UI related events  A component can act as three different kinds of roles for an event: Producer, Consumer and Observer eg. an Application is producer of key press/release events An Input Method Engine is consumer of key press/release events  Components can be categorized by different set of events and event roles.

9. 9 Technical details (3) Component registration and communication  Components provide necessary descriptive information and a list of supported events and roles when connecting to IM-BUS daemon  IM-BUS daemon allocate an unique ID to each component  A component can query information of other components from IM-BUS daemon  A component can communicate with other components by component's unique ID  IM-BUS decides whether to deliver an event or not by corresponding event roles of source and destination components

10. 10 Technical details (4) Input Context and Event structure  IM-BUS daemon maintains information of all ICs: Associated Application and Input Method Engine Is focused or not  An event can be sent to a specified IC, which will be sent to corresponding component associated to it.  An event which is sent to an IC instead of a specified component, can be observed by other components. An event includes:  Source component ID, Dest component ID or Input Context ID.  An event type, timestamp and serial number  Arbitrary data

11. 11 Technical details (5) A sample workflow  An application send create IC event to IM-BUS daemon  IM-BUS daemon forward it to default IM Engine and record the information of this IC, then return an IC ID to the application  The application send Focus In event to IM-BUS daemon for the IC  IM-BUS daemon forward it to corresponding IM Engine and record the state  The application send a key event to IM-BUS daemon for the IC  IM-BUS daemon forward it to corresponding IM Engine as well as the components which want to observe it  The IM Engine send arbitrary UI related events to IM-BUS daemon  IM-BUS daemon forward them to corresponding UI components  The application send more key events to the IM Engine via IM-BUS daemon  The IM Engine send commit string event to the application via IM-BUS daemon

12. 12 Roadmap 2004:  NEA-OSS WG3/SWG1 established 2005-2006:  Technical investigation  Draft specification of feature requirements 2006-2007:  IM-BUS project development undergoing. End of 2007:  Release the first prototype of IM-BUS (hopefully).