Like all add-ons, Input Server add-ons are compiled as shared libraries. The add-ons must link against input_server, renamed (as a symbolic link) to _APP_. In other words, you set up a symbolic link like this:

$ cd <yourProjectDirectory>
$ ln -s /boot/beos/system/servers/input_server _APP_

And then link against _APP_.

The input server looks for add-ons in the input_server directory within B_BEOS_ADDONS_DIRECTORY, B_COMMON_ADDONS_DIRECTORY, and B_USER_ADDONS_DIRECTORY. Where you install your add-ons depends on what type of add-on it is:

• input_server/devices is for input devices

• input_server/filters is for input filters

• input_server/methods is for input methods

• You can install your input devices in the latter two directories—i.e. those under B_COMMON_ADDONS_DIRECTORY, and B_USER_ADDONS_DIRECTORY.

• The B_BEOS_ADDONS_DIRECTORY is reserved for add-ons that are supplied by the BeOS.

The Input Server automatically loads (or attempts to load) all add-ons at boot time.

Currently, the Input Server doesn't dynamically load add-ons. This is a particular annoyance if you're developing and testing an add-on. To work around this lack, move your add-on into the appropriate directory, and then quit and restart the Input Server from a Terminal:

/system/servers/input_server -q

This will gracefully shutdown the Input Server and then re-launch it. The first thing the Server does when it comes back up is re-load the add-ons from its add-on directories.

Your mouse and keyboard (and other input devices) will go dead for a moment while this is happening. This is normal.

The Input Server extends the plain B_MOUSE_MOVED message (which triggers a BView's MouseMoved() function) beyond its ordinary existence to let things like tablets pass along extra information about a user's actions. For example, drawing tablets can track the user's movement with greater precision than a mouse, and can include drawing pressure and tilt information. Some also include an "eraser."

If an application can do something useful with this information (and let's face it; drawing applications that respond to pressure and tilt on a drawing pad are useful as well as being cool), it'll be present in the B_MOUSE_MOVED message:

void MyView::MouseMoved(BPoint *where,
                         uint32 transit, BMessage *drag_msg)
{
   BMessage *moved_msg = Window()->CurrentMessage();
   ...
}

The extra information that a "mouse" input device could add to the B_MOUSE_MOVED messages includes:

• more precise position information

• drawing pressure

• pen tilt

• "eraser" mode

Tablets store the absolute position of the pointer with as much precision as they can in the be:tablet_x and be:tablet_y fields:

float x, y;
x = moved_msg->FindFloat( "be:tablet_x" );
y = moved_msg->FindFloat( "be:tablet_y" );

These entries will be scaled to the range [0.0 to 1.0].

Tablet pressure is stored as a float in the range [0.0 to 1.0] (minimum to maximum), present in the be:tablet_pressure field:

float pressure;
pressure = moved_msg->FindFloat( "be:tablet_pressure" );

Pen tilt is expressed as a pair of floats in the range [0.0 to 1.0], where (-1.0, -1.0) tilts to the left-top, (1.0, 1.0) tilts to the right-bottom, and (0.0, 0.0) is no tilt. These floats are found in the be:tablet_tilt_x and be:tablet_tilt_y fields:

float tilt_x, tilt_y;
tilt_x = moved_msg->FindFloat( "be:tablet_tilt_x" );
tilt_y = moved_msg->FindFloat( "be:tablet_tilt_y" );

The pen's eraser mode is expressed as an int32 in the be:tablet_eraser field:

int32 erase_mode;
erase_mode = moved_msg->FindInt32( "be:tablet_eraser" );

A value of 1 means the pen is reversed (i.e. the eraser is on) and 0 means the pen is behaving normally. Other eraser modes may be defined in the future.

When interacting with an input method, your view's MessageReceived() function will receive B_INPUT_METHOD_EVENT messages; inside is a be:opcode field (an int32 value) indicating the kind of event:

In between the B_INPUT_METHOD_STARTED and B_INPUT_METHOD_STOPPED messages, you'll receive various B_INPUT_METHOD_CHANGED and B_INPUT_METHOD_LOCATION_REQUEST messages as the transaction proceeds.

B_INPUT_METHOD_CHANGED does most of the work in an input transaction; its message contains the following important fields:

B_INPUT_METHOD_LOCATION_REQUEST is the input method's way of asking you for the on-screen location of each character in your representation of the be:string. This information can be used by the input method to pop up additional windows giving the user an opportunity to select characters from a list or anything else that makes sense. When you get a B_INPUT_METHOD_LOCATION_REQUEST, reply to the be:reply_to messenger (that you saved from the B_INPUT_METHOD_STARTED message) with a B_INPUT_METHOD_EVENT message, filling in the following fields: