IMG Home PageIMG ProductsProduct DownloadsOrdering InformationTechnical Support and Frequently Asked QuestionsDeveloper's Corner and UtilitiesAbout IMG
CustomersIMG ResellersMedia InformationIMG Events / Trade ShowsUseful LinksIMG Contact InformationIMG Information / Policies


Build-A-Board Overview & KeyBoard File (KBF) Architecture

Build-A-Board has been under constant development since its beginning as a developer's tool, primarily focused on creating on-screen keyboards and deploying user interface components on various platforms, all while being influenced from customer demands, new technology, and changing uses of computing devices. Being software, and implementing a flexible, yet solid core of well-designed software, while targeting multiple operating systems and platforms (which often go through considerable changes on a regular basis) is an on-going challenge. This is a quick overview of the structure & design of Build-A-Board.

Distinct components

Builder

The Builder is the user interface component that gives flexibility to the keyboard layout designer. It provides certain functions and capabilities that may not be desirable for an operator using the on-screen keyboard. In practice, it is often used by a developer, and 1 instance of the Builder may be responsible for thousands of run-time keyboard deployments. It is treated as a "rich" application, and is constrained differently than the run-time aspects. Also, there are multiple builder tools - Windows based application, and a web-based application.

Note: The web-based application is not yet publicly available as of this release

Source Files

The Source Files (or SOURCE project) is the definition of the keyboard layout as managed by the Builder. It exists in different ways - internal memory structure within the Builder, Text files in the Project SOURCE folder, database records, with translation methods available to manage these. Note also that using the utility KBFDUMP, a Data file KBF can be extracted to Source files.

Compiler

The Build-A-Board Text Compiler (BABTC) is used to read and condense the information in the Source Text files into the binary representation. This approach is used to ensure the Data component can be in as small a footprint as possible, and the translation from Source to Target usable representation forces design discipline & also provides data validation/verification.

KBF (Data)

The KeyBoard File (KBF) structure can be viewed as a flat file database, or as multiple files joined with an index table. Once built, the file size is fixed - any user-modifiable options/variables/areas are constrained to existing data size locations in the KBF. This approach is a result of various factors:

The current information stored within the KBF File:

Run-Time Targets (Program)

The original design goal was to have a Program/Data type approach - i.e. My-T-Soft (Program) presented the keyboard layout contained in the KBF (Data) file. Depending on the system, there are sometimes other support files (Libraries or data files), and the Program is often 2 processes (one handling user interface & the other key actions). As much as possible, limiting the required Run-Time files is the preferred approach. Certain aspects (i.e. image support/library calls/executables) are treated as "non-core" capabilities of the software, and these are handled with additional files when required (e.g. PNG images are handled natively in the Mac OS X API, but require libpng in Linux, and interfacing with GDIPlus.dll in Windows via the gdikit.dll add-on).

The run-time target approach (on most platforms) is to separate the user display / user interface, and the resultant key actions as separate processes. The MYTSOFT/My-T-Soft/mytsoft process is responsible for the user interface, and the Macrobat/macrobat process is responsible for the macro batch processing (key actions). This is done for various reasons:

In other words, the design approach used is that the user-interface is just a way for the user to tell the computer to perform an action. Since this action could theoretically be anything imaginable, it is unlikely that every possible action could be embedded into one process. Therefore, treating the action as an event to be handled by some other process is the best design approach to use, resulting in a separate process to handle the keyboard actions (i.e. Macrobat). So even though the use as a keyboard is the default Key Action, the underlying design just treats this as one of many possible Key Actions.

Android / Input Method type interface - newer platforms treat the keyboard and text input in an integrated approach, which provides its own set of benefits and limitations. Because the text processing / input is more of an extension of a system edit control/field (vs. a separate, independent text input device), certain aspects must be handled in a system compatible fashion. Because this system interface has various aspects dictated by the system itself, features and capabilities typically have to be implemented based on the available options provided by the platform. Because this inherently results in its own platform-based implementation, features and operation may be different than other platforms, and not all features may be available.


IMG Home PageIMG ProductsProduct DownloadsOrdering InformationTechnical Support and Frequently Asked QuestionsDeveloper's Corner and UtilitiesAbout IMG
CustomersIMG ResellersMedia InformationIMG Events / Trade ShowsUseful LinksIMG Contact InformationIMG Information / Policies


As seen in ...

Yahoo!finance