10 September, 2007

An interface design issue of scim

SCIM's panel module is responsive for all GUI-related works. During user typing, it will show a lookup-table window to allow user choose what he/she want according to his/her input.

To support multiple IMEngine, SCIM defines a pair of signal/slot, whose name is update_lookup_table, to allow IMEngine sending the content of lookup table to panel. The prototype of this slot is:

void update_lookup_table(const LookupTable &);

Here LookupTable is an abstract class, IMEngine may use any class derived from it to store the content of lookup table. It's cool for all-in-one-process solution, which offers more flexibility.

But in most cases, SCIM runs in a multi-process mode, that is, IMEngines run in the scim daemon process, panel runs in a scim-panel process and IMModule runs in the client application's process. To exchange info, these processes communicate via standards socket connection. The problem is, the receiver in one process has no idea about the actual type of this LookupTable in another process. The current behavior of the receiver is using CommonLookupTable, which is derived from LookupTable, to store and manage the content it receives and offer this CommonLookupTable object as a LookupTable to other part of code.

Currently LookupTable has only one subclass, i.e. CommonLookupTable. It won't bring real benefit if declare the type of this argument as a abstract class. IMHO, it should be CommonLookupTable directly.