Keyboard Input

To input a script that uses thousands of characters, there must be a process that composes the input from a keyboard, which has less than 100 keys into an appropriate character in the extended character set. The software component that takes responsibility of this composition is often called an ``Input Method'' or a ``Front End Processor''. Ideally, this input method would be written in Squeak, but today we rely on the underlying OS.

4: Placement of Composition Window.

(A)

(B)

(C)

Some methods in are modified so that the keyboard input data from the VM is converted to the appropriate or instance. The default behavior of and is to pass the each octet to the as a character, but for multi-octet characters, the sensor has to combine more than one octets and create a multi-octet character. The correct translation varies depending on the default encoding scheme of the underlying OS.

For the Japanese version of Windows and Mac, the encoding scheme is called Shift-JIS. a Shift-JIS character consists of two octets and the first octet's 8-th bit denotes that it and the subsequent octet are the part of the same character. When the method sees an octet with 8th bit set passed from the VM, it ``peeks'' at the next octet. If the OS passed a Shift-JIS character, this peek attempt always succeeds so that the method can combine those two octets.

The current implementation of treats the Shift-JIS encoding specially, but we are planning to add a generic way to switch the encoding.

The other convenient function on a Japanese system is so-called ``inline composition.'' Typically, the input method shows its own separate window to display the characters being input. To indicate where the string being input goes, the composition window should be placed at the exact position where the string will eventually appear. This sensible composition window placement is called ``inline composition''. The figure 4 shows the screenshot where the inline composition is not enabled (A) and enabled (B). In (A), the compositing window is placed at regardless of the position of the window where the user wants to input the text. When the user confirms the intermediate string, the result is passed to the VM and eventually shows up in the FillInTheBlank (C).

The more desirable behavior is shown in figure (B). The compositing window is already shown over the and once the user confirm the intermediate string, the string is already in its final position resulting in less surprise and eye-movement.

We have implemented a Windows .dll (plugin) to enable inline composition. To tell the keyboard focus position to the OS, is modified and the morph that gets the keyboard focus tells the ``'' where to place the composition window. Then the composition manager calls a primitive in the plugin and the primitive eventually calls the Windows API. #..tex#;''