LibStylus Design Document

Tomas Frydrych <tomasfrydrych yahoo co uk>

Revision History

10 November 2005: Initial version.


One of the challenges for a hand-held device is optimatisation of user input in the absence of traditional keyboard and mouse. A possible and common answer is to provide a presure sensitive screen and a stylus. While on the most basic level in this scenario the stylus replaces the mouse, typically it will be accompanied by a virtual (on screen) keyboard and handwriting recognition software that allows it to be used in the place of a keyboard. However, both the use of virtual keyboard and of handwriting recognition can be tedious in real life, particularly where the screen is small.

At the same time, the stylus is not a mouse, but rather a pen and there are situations where pen-like input is much more natural than using a keyboard, and where an emulation of the oldfashioned paper-ink model opens new possibilites for use; this is where electronic ink comes in: the idea is to allow the user to scribble into existing documents using their stylus (for some illustrations, see the home page of TAbiWord).

Conceptually the idea of using electronic ink in an application is simple but its implementation requires certain amount of low-level processing that would need to be duplicated in each application. The aim of libstylus is to provide an API that would allow an application to implement ink support without having to deal with the low level issues.

Overal Design Considerations


Needed API

Input modes

An object to encapsulate ink

API to transform ink objects

API to query ink properties

API to set ink properties

API to draw ink object

API to associate application-specific data with the object

API to serialise ink

API to facilitate conversion of ink to other media

Basic Design

The library will be of modular design consisting of a frontend and a backend.

LibStylus FrontEnd

LibStylus BackEnds

The library will contain one or more backends, each of which will provide two sets of services to the front end:

The functionality of the backend is encapsulated by an abstract class STY_Backend; each backend will implement a derrived class of it.

The backends are managed by STY_BackendManager, a singleton class that facilitates the creation of required backend instances by the application.

Current plan is to provide a backend using the AbiWord application framework and a generic gtk backend. A Qt based backend would be desirable (contributors are welcome). (Should it be desirable, the application can provide also it's own backend.)