[Uim] What's going on: the composer framework
YamaKen
yamaken at bp.iij4u.or.jp
Tue Jul 12 21:04:09 EEST 2005
Hi all, I've defined Scheme version of the composer API of the
composer framework for public review.
Please let me know your requirements and opinion about it.
This message is written as explanation for developers. Benefits and
features for endusers are not well described. Please wait for another
opportunity for it.
What's going on: the composer framework
1. What is composer framework?
2. Architectural problems of current uim
3. Key components of the framework
4. An example of composer-based IM
5. FAQ
6. Roadmap
1. What is composer framework?
The composer framework is the core architecture of next generation uim
completely restructured by me.
It is intended to resolve several architectural problems of current uim,
make input method development easy, enables functional improvement by
developing a reusable component instead of hacking entire input method,
provide appropriately separated components to construct platform-specific
useful IM environment, and enables flexible IM customization.
The framework itself does not assume fixed design policy of user-level IM
environment or operation scheme. They are upper layer issues and what the
framework should do is making any system organization possible by
providing reusable components with proper responsibility separation. A
name "IM toolkit" for the framework and a name "IM environment" for the
upper layer may help your recognition about the responsibility of the
framework, on the analogy of "GUI toolkit" and "desktop environment".
Of course the upper layer is important part of uim. I believe that the
layer separation will make development of platform-specific IM environment
easy.
The framework is being developed in another branch (composer branch).
2. Architectural problems of current uim
- UNIX desktop-centric monolithic facilities
* module (plugin) management
* fixed-style input context instantiation
* fixed-style input context management
* fixed-style IM switching method
* locale-aware IM selection
- too complex management scheme of input context
* the instantiation process and instance representation itself are
involving several facilities distributed in C and Scheme. So we cannot
simply instantiate and use an input context from Scheme
- insufficient responsibility separation and reusability
* a code can easily be broken with unintended responsibility violation
of another code modification
* too many copy-and-pasted codes are preventing improvement
* the copy-and-paste code bloating must be stopped and recover health
before it become black magic materials
The solution for these problems will be told by code.
3. Key components of the framework
- composer
* a composer instance is mostly an input context
* composer offers a set of polymorphic methods
* a composer instance can return its text currently composed in response
to a getter invocation from its owner
* composer instances can be organized as a tree whose each node is a
composer instance
* a composer instance of the tree merges text fragments of its children
under its own rule into text of itself
* C binding of composer API may be provided in future and a composer
written in C and in Scheme can be mixed into single composer tree
* see current implementation for further information
http://lists.freedesktop.org/archives/uim-commit/2005-July/000850.html
- action
* completely rewritten as ng-action.scm from former action.scm
(interface is also different)
* abstracts a composer-specific operation to be exported and controlled
from outside of the composer
* actions are used to be bound to arbitrary key sequences, choosable
item of a chooser UI, or simply activated by action-event from
anywhere (including client application)
* each action has a precondition predicate indicates that the action can
be activated now. it is used for implicit per-state key bindings by
evmap
* the 'self' object for the action handler is held in action
object. activator of the action object does not need to know what is
activated
* activation by name instead of live action object enables polymorphic
action handlings differently behave in accordance with recipient
composers
* see current implementation for further information
http://lists.freedesktop.org/archives/uim-commit/2005-July/000829.html
- chooser
* an abstraction for user interaction about choosing something
* used to choose candidate, input mode, input method and so on
* consists of three participant objects organized as classic MVC model
Model: choosable (exported by a composer)
Controller: chooser (a composer)
View: chooser widget (an abstract event-driven UI)
* candidate window, toolbar, message buffer located in a text segment of
preedit and so on can behave as a chooser widget
* chooser widget can be replaced as user want
- evmap
* a mapper that maps arbitrary event sequences to another sequence
* used to compose string, binding key operation to actions, translate
key event, and so on. it replaces traditional rk
* can backtrack (undo) its input sequence
* can detect flexible key operations such as multistroke, simultaneous
key press (chord), physical key position information and more
* can behave as a composer by evmap-composer
- utext
* a flexible text representation
* can contain multilingual texts that has different encodings
* can add arbitrary text properties such as locale, visual modification,
ruby (Japanese phonetic annotation) and so on
* see current implementation for further information
http://lists.freedesktop.org/archives/uim-commit/2005-July/000830.html
4. An example of composer-based IM
The figure below illustrates a possible Japanese multi-segment kana-kanji
converter IM based on composer framework. See it as really example. Actual
IM will have more complex tree structure.
Each node is a composer instance and they are connected with each other by
uniform abstract composer interface.
client (bridge)
|
commit, preedit, etc ^|| key, action, chooser events and so on
||v
|
event-dropper (for dropping key release properly)
|
key-translator (key remapping and modifier translation)
|
vi-adapter (snoops vi commands and issue actions)
|
event-translator (as key -> action mapper)
|
mru-chooser (as part of IM switcher)
|
multiplexer (as part of IM switcher)
||||
|||+------------------------------+
||+------------------+ |
|+------+ | |
| | | |
| another IM another IM another IM
|
lazy-instantiator
|
event-translator (as key -> action mapper)
|
chooser (for controlling candidate selector)
|
kana-kanji-converter (more complex composer tree inside)
|
migemo-seeker (move cursor by incremental migemo search)
|
row-editor (edits a row of composers)
||||
+-----------------+||+-----------------------+
| +---++---------+ |
| | | |
skk-composer evmap-composer py-composer evmap-composer
go cha ma z
▼誤 ちゃ 媽 z
5. FAQ
Q. The framework seems heavy. Can it be usable?
A. Yes, I believe. Memory consumption will be minimized by Scheme-specific
way, and polymorphic method invocation will be tuned as significantly
optimal. And Kazuki's SigScheme will provide more headroom for
optimization.
Q. Is such complex structure really needed?
A. Yes. I want to develop many special features other than ordinary input
method. To sustain such continual extensive development, features of input
methods should be separated unifunctionally and flexibly removable,
reconfigurable relationships between other parts with narrow
interface. The composer interface is my solution for it.
In addition, although the tree structure seems complex, each composer
implementation tends to be simple. If you still feel it complex, you can
write a monolithic composer contains all features of the IM.
Q. What is achieved by C binding of the composer API?
A. There are multiple values.
- enables writing a composer without touching Scheme
* form preexisting IM implementation written in C into a composer
* language bindings for other than C
* IM manager, switcher and so on written in C. uim will not provide it
in accordance with its Scheme-centric policy to maximize benefit from
the language
- enables running libuim without Scheme interpreter
* simple composer written in C without IM switcher and so on
* IM manager, switcher and input methods entirely written as C composer
* composer proxy written in C connected to uim-agent or uim-server
- makes experimental development easy
* directly link an IM implementation as library that exports the raw
composer interface
* directly instantiate a composer by library-specific factory method
such as foo_composer_new()
* no IM repository, plugin, indirect instantiation, locale-based
automatic processing, IPC or IM switcher
* the direct linking makes experimental development easy without being
bothered by intermediate layer. for example, accessing to a
client-side construct is very easy
Q. What do you think about an unified IM API?
A. It's difficult to adopt for uim at now.
Although I hope an unification of the API between several IM frameworks
for input method developer and bridge developer to enable writing an IM
component regardless of which IM framework uses it, the unification will
bring a significant loss to uim, at least for now.
Since the composer framework has some unique abstraction model different
from its counterpart of other IM framework, an API unification forces
unnatural limitation to either uim or others. Instead of such unification,
maintaining a unidirectional framework bridge such as uim-scim or scim-uim
is reasonable solution for now, at least until uim 1.0.
Although wide-range unification is not beneficial, simple things such as
key symbol definitions can be shared. I'll consider it when the time has
come.
6. Roadmap
My roadmap is shown below. Other developers maybe have another. Let me
know your plan if something is conflicting.
- 0.5 (devel) and 0.6 (stable)
main goal: establish the composer framework roughly
schedule: several months after
* merge the codes from composer branch into trunk
* add ng-anthy IM based on composer framework. former version of anthy
may coexist if ng-anthy is not lightweight enough
* add ng-canna IM if some lacking features of canna.c is complemented
* ng-anthy and ng-canna will be registered as legacy IM via API adapter
* support dead keys and Japanese "RO" key in libuim and bridges
* add icon, separator and single action button support to helper
protocol and toolbar
- 0.7 (devel) and 0.8 (stable)
main goal: internal cleanup by the framework
schedule: should be released before the next year
* port all input methods to composer framework
* replace the IM management codes written in C (related with
uim_im_array) with composer-based one
* the context management codes written in C (related with context_array)
will be kept
* replace the IM switching codes written in C with composer-based one
* enable flexible IM switching by key operation, candidate selector, etc
* enable flexible toolbar customization using chooser and action
* obsolete many legacy codes inside libuim and scm, but C APIs will be
kept untouched (including uim_switch_im())
* support advanced key bindings with uim-pref if someone want to develop
it
- 0.9 (devel) and 1.0 (stable)
main goal: revise the uim API
schedule: next year
* obsolete and discard former libuim codes
* add C binding of composer API
* replace the uim API (uim.h) and helper API with composer-based one to
simplify and get advanced features
* provide some API wrapper for composer API to make connecting composer
to client (bridge) easy
* replace helper system with something that can handle the interactions
via appropriate backend for each platform
* rewrite candidate selectors as generic chooser
* rewrite toolbar as generic chooser
* simplify bridges in accordance with above changes
* restructure the custom facility and API, and revise uim-pref
-------------------------------
YamaKen yamaken at bp.iij4u.or.jp
More information about the uim
mailing list