[Uim] What's going on: the composer framework
TOKUNAGA Hiroyuki
tkng at xem.jp
Fri Jul 22 00:54:19 EEST 2005
Hi,
I don't see actual implementation of composer framework yet. So that's
only my feelings.
I agree the basic idea of composer framework.
I strongly agree with the concept of chooser.
I doubt the idea of lazy-instantiator. (i.e. I'm thinking all im should
be loaded automatically (if possible.))
To tell the truth, you may not believe, I want to release 1.0 as soon
as possible. (If possible, I want to release 1.0 until the year end.)
Now I'm not thinking composer framework is must item for 1.0, because
this big reorganization is likely to cause some troubles. Introducing
new code would cause drop-off in quality temporarily.
Is is possible to introduce composer framework without affection to
other parts?
Regards,
--
TOKUNAGA Hiroyuki
tkng at xem.jp
On Wed, 13 Jul 2005 03:04:09 +0900
YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> 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.
I don't think adopting unified IM API to application side of libuim is
difficult. But, to input method side, yes, it would be difficult.
> 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
Is this schedule possible? Of course schedule depends on the numbers of
contributers, but now we have no full-time commiter. I guess this
schedule is very aspiring and would be hard if we cannot get some new
contributers.
> * 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
More information about the uim
mailing list