For the last 15 years I've been complaining about input method
approaches being unnecessarily complicated. The problem has been that I
never really had time to produce a reasonably complete proof-of-concept
that I could provide publicly. I have finally made a start, and the
links at the end of this message will lead you to what I have so far.
I want to present some ideas that should be considered in developing a
new framework. These ideas are distilled from 17 years of developing
multi-lingual software and discussing and observing end users editing
multi-lingual text.
I want to stress that these ideas should be not be considered the final
word about anything or the "correct" way to do things, but they are useful.
---------------------------------------------------------------------------
VOCABULARY
----------
I typically divide input methods into two categories: basic, and complex.
"Basic" refers to any input method that can be handled with just a basic
keyboard layout (which may include several levels) that produces strings.
"Complex" refers to any input method that processes whole
phrases/sentences/paragraphs/documents at one time. "Complex" examples
are the various Pinyin->Hanzi/Kana->Kanji/Hangul->Hanja conversion
servers out there.
IM IMPLEMENTATION LANGUAGE
--------------------------
The "language" used to implement input methods should be extremely
simple. We tried many different programming/scripting languages over the
years. The result was that users generally found input methods too
difficult to modify directly, even when they were familiar with the
language. We always had to build another complicated layer on top to
simplify creation/editing of input methods.
Over the years we eventually distilled expected text input/editing
behaviors into a syntax somewhat similar to what you will find in the
GIM HTML file linked below. The GIM syntax as presented below is
sufficient to handle all basic input method needs that we encountered
over the years except for candidate selection, which I am adding when I
have time. Candidate selection capability for basic input methods adds
2-3 new keywords to the GIM syntax.
The benefits of a simple, restricted syntax should be clear: less room
for error, small memory footprint, simple to implement, easier for end
users to modify, and so on.
BEHAVIOR AND PRESENTATION
-------------------------
One very useful result of the distillation was the realization that both
the behavior and the presentation of the keyboard can be combined. The
virtual keyboard layout is developed at the same time as the input
method. A virtual keyboard program can make use of the behavior
specified in the input method to provide visual feedback to the user.
IM FRAMEWORK
------------
Ideally, the input method framework would be at the lowest userspace
level in the OS, handling keystrokes without a lot of intermediate
steps. Alternatively, it would be nice to have a framework that could be
incorporated into the commonly used GUI toolkits, which would require
acceptance from their respective developer communities.
The two options for a new IM framework are client-side input methods and
server-side input methods.
Most of the current frameworks are server-side and tend to work OK.
Although I have not been paying close attention to this, it seems to me
that most of the current problems are not really with the server part of
things, but with the input method and user interface part of things.
My opinion is that a modern IM framework should provide both client and
server-side options -- client-side so an application can ship with only
the input methods it requires and is not dependent on an existing
server-side setup on the client machine, and server-side for all those
applications that are never going to be rebuilt to include a client-side
library.
SUMMARY
-------
I'm out of time and this is getting too long. Basically, I believe that
the work being done on the current IM frameworks has provided a lot of
valuable experience. Perhaps now is the time to start thinking about
picking and choosing the parts that work the best from the different
approaches, with a focus on simplicity.
More thoughts on a new framework later.
---------------------------------------------------------------------------
NOTES: The GIM package only works for GTK+ at the moment and does not
support CJKV conversion servers yet. I may or may not have time to
answer questions about installing GIM.
http://www.math.nmsu.edu/~mleisher/Software/gim/gim.htmlhttp://www.math.nmsu.edu/~mleisher/Software/gim/gim.tgz--
Mark Leisher
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
Scim-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/scim-devel
