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

• Source Files

• Compiler

• KBF (Data)

• Run-Time Targets (Program)

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.

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:

• For embedded systems, or for secure operator situations, having a read-only, fixed Keyboard File (as similar as software can be to a physical hardware based keyboard in this context) was deemed an important aspect during the original design, especially for hardware engineers implemented an on-screen keyboard as a replacement to a physical keypad. This "fixed" aspect adds a level of comfort for hardware engineers when working with the software. Also, the software must also operate correctly in situations where the data is ROM (Read-Only Memory).

• A single Data file ensures easier handling for system administrators, integrators, and end-users.

• Add-ons are easy to manage - additional files can be added to the single-file structure with very little effort.

• In practical usage, once a fixed layout is accepted, changing it can have adverse affects on standard and limited operators, so treating the KBF as a fixed end-result works best (and it can always be changed with the Builder, so there is no down-side to this approach, however, any other approach may be unacceptable, i.e. secure operator situations where the operator must have NO configuration options).

• Multiple KBFs can be used with the New KBF (CMD:NKBF) and Load KBF (CMD:LKBF) commands

• Conceptualizing the Keyboard layout AS the KBF itself works better from experience than working with the separate layout and labels/actions aspects (see the KMF/KBF structure in the IMG My-T-Soft Family (1.xx))

The current information stored within the KBF File:

• File signature and version, along with reference/lookup (index) into the rest of the file.

• Window data - location, size, frame type, etc.

• Panel data - location, size, frame type, etc.

• Key (Button) reference data - location, sequence.

• Key data - size, labels, actions, colors, etc.

• State data - reference information on possible operational states, etc.

• Image data - Image scripts used for Keys, Panels, Windows.

• Action data - Action scripts used for Keys, Panels, Windows.

• License data - License for KBF / Platform License if applicable.

• INI data - Initialization file (INI), includes General Program settings, User modifiable settings.

• KMF data - Keyboard Macro Files, default key mappings, etc.

• Image files - Image files as PNGs.

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:

• Interoperability - different operating systems handle virtual input differently, so keeping this operating system specific portion as a separate process reduces potential conflicts.

• Flexibility - by having the input handled by a virtual input server, this process can provide these services to other processes in the system.

• Historical reasons / future extensibility - The Macrobat (Macro Batch) processing syntax and handling as a separate process is integral in various IMG products, and this is seen as an important architectural design for the future. For example, having a specific computing devices as a user-input device (e.g. a separate handheld device) and then requiring the keyboard input on a different, main device, i.e. REALLY separating the user interface from the virtual input process!

• Approach - from experience, having 2 distinct aspects managed in separate ways provides a much more robust approach. For example, some MIDI (Musical Instrument Digital Interface) devices use a controller / synthesizer design approach, where the user based controller (e.g. piano type keyboard, or guitar) can run the synthesizer directly, but the device's synthesizer may also be controlled via external MIDI. Designing the run-time approach in this way provides other capabilities and options that would not be available if the user-interface was tightly integrated with the virtual input server.

• Arbitrary Key Action - initiating a Key Action based on a user input can also be extended to other arbitrary events, handled by the Macrobat process, or handled by a completely different process (or contained in a library), or even handled by system or other available services. This provides even more flexibility to a keyboard, i.e. providing non-keyboard based actions.

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.