With more & more new users, many of whom are creating layouts with My-T-Soft^® Build-A-Board, occassionally there are questions regarding the keyboard layout files, their naming conventions, and what they are all about. In this entry, we will cover some history, some relevant details & distinctions, and a look into the future.

In the before time, the original release of My-T-Mouse utilized 3 main types of configuration files - files with .KBF, .KMF and .INI extensions. The keyboard data file was named with a .KBF extension for KeyBoard File. This data file contained panel rectangles, key rectangles, and window configuration information. The actual key labels and key actions were contained in the .KMF files - Keyboard Macro Files, which lended itself well to international / different keyboard layouts (same physical layout, different labels/key actions). User configuration information was in the initialization file, or MYTMOUSE.INI. Because certain data spanned the user configuration and had an effect on the keyboard display (i.e. size, visible keys, panels open, etc.), the intertwined nature of the .INI and .KBF file became a factor when working with the 1.xx software. Because of this, for best results when manipulating the keyboard software, using BOTH the .INI and .KBF files as a matched pair was recommended when externally controlling layout changes.

Due to various user interface conventions and customer requests, along with design considerations, the .KBF file became more & more flexible, and could be manipulated in various ways. For example, when the keyboard software is opened, it reads in the data file (.KBF file), along with user options (.INI file) and then configures things based on these settings (the KMF file in use relied on the Keyboard= setting in the .INI file). Since the user could have changed the .INI file via the separate Setup tool (or programmatically via Developer Kit tools), settings such as layout size might need to reconfigure the data read in from the current/saved .KBF file. The general approach was that user settings in the .INI overruled the .KBF file. However, due to design decisions and the possibility of impossible manipulations because of certain internal constraints, it became necessary to require that both the .INI and .KBF be a matched pair when being used to create multiple configurations for "on-the-fly" layout changes.

When the 2.xx software was designed, keeping the .KBF as the single / only data file was deemed the best solution. Having multiple files that needed to be managed to ensure proper display/operation is not keeping in line with making things as straightforward and as easy as possible for users and developers, so the single .KBF file per layout is how things work with the 2.xx software. Because there are many examples of "user" or "field" settings that need to be part of the keyboard layout data, an embedded MYTSOFT.INI has been incorporated into the 2.20 KBF data structure. This allows tools such as KBFEdit to open and modify these user based settings in the field by the user, allowing certain customizations for operational aspects and user settings.

In most cases, the single .KBF as data for a keyboard layout, with incorporated operational aspects works very well - in the spectrum of ideal to acceptable. However, there are situations where there are issues. Cases where the user should not be able to make modifications, or where there are many layouts and user settings should be "per user" can be accommodated, but not as easily as program/user options separated from the layout data. But before we touch upon future enhancements, let's review how the current Build-A-Board system works and creates .KBF files.

The Build-A-Board Builder creates its own sub-folder in the Public Documents location, and under the Build-A-Board folder, there are 3 folders: SOURCE, TARGET, BOARDS. Under the SOURCE and TARGET folders, there are Project Name folders. Let's use an example, and walk through the general steps. If you create a project called MyAwesomeLayout, you will get a sub-folder in SOURCE\MyAwesomeLayout. In that folder you will find all the source files that contain the information displayed in the Layout Builder - window size, keys, key sizes, key labels, key actions, etc., etc. When you close a project in the Builder, all the text and data files will be zipped up (i.e. compressed) into a single Project source file, e.g. SOURCE\MyAwesomeLayout\MyAwesomeLayout.zip.

When you open a closed project, it will be unzipped, and all the data from the project source files will be read in to the Builder, and the customizable layout will be presented, where properties, actions, etc. can all be modified. Then you can select a Run-Time Target - Linux or Windows, ANSI or UNICODE, 32-bit or 64-bit, and various other platforms & combinations of run-time targets. When you Build the project, the Project Name folder in the TARGET folder will be created, along with a Test sub-folder and the target folder, e.g. MSWIN32 for Windows 32-bit targets. So the run-time files for Win32 would be in TARGET\MyAwesomeLayout\MSWIN32. This folder could be copied to a Win32 system, and the MYTSOFT.exe can be run, showing the MyAwesomeLayout layout. In the TARGET\MyAwesomeLayout there are 2 .KBF files - MyAwesomeLayout.KBF and KEYBOARD.KBF. These are also in the Test folder (used for testing/running on the system running Build-A-Board), and in any run-time target folders. Also, the MyAwesomeLayout.KBF is copied to the BOARDS folder - so when the Board select option is used in My-T-Soft, it will appear as a board option to select.

The reason there are 2 .KBF files is that by default, when My-T-Soft is run, it will look for and run KEYBOARD.KBF - so each project always copies the Project Name .KBF file to KEYBOARD.KBF. The reason the project name is used (e.g. MyAwesomeLayout.KBF) is for dealing with many different projects, so each unique project has a unique .KBF file name.

So what data does a 2.xx .KBF file contain? For those that are interested, it is pretty easy to review the text files in the SOURCE folder for an open project and get a general idea. These are the main aspects of a layout file: Window information, Panel information, key positions, and then key information. Then there is supporting data - key images, base & international macro files (.KMF data), state data, image data, platform license data, and the MYTSOFT.INI. As much as possible, the user interface and operational aspects are controlled by the .KBF file / layout data.

So what does the future hold? There are actually many different items under development and slated for future enhancement regarding the .KBF KeyBoard File. As a single data file that defines the keyboard, the 2.xx approach has been deemed a success. To accommodate user specific options, an override approach has been defined as the best/most flexible. The way this will be implemented will be a user editable MYTSOFT.INI which can contain a subset of all possible entries, and those that are in the MYTSOFT.INI in the user application data/configuration area will be used as the actual setting, potentially overriding any matching setting in the .KBF file. Note that these user settings will apply to all .KBF files run, so any user settings set in this manner will apply to all layouts run. This approach will allow multiple users on a system to have different operational settings, all while using the same .KBF. If there are not user specific settings, then the settings in the .KBF will be used.

The general approach is for .KBF files to be layout files that can be used across multiple platforms. Because of platform differences, certain aspects of the layout may be interpreted differently based on the platform, screen resolution, system capabilities, etc. How these will continue to evolve depends on actual use cases and customer requirements. Although not yet formalized, the 3.xx release anticipates merging all capabilities of 1.xx and 2.xx software, along with additional capabilities incorporated based on real world customer input. As the original .KBF implementation passes 25 years of use, a nod can be made to its original design & flexibility, and a hearty thank you to the customers that have used and continue to implement the software to address and solve real world needs.