-
-
Notifications
You must be signed in to change notification settings - Fork 107
Keyman Glossary
People using Keyman Developer, keyboard language, creating keyboard layouts. 'Keyboard authors' in full, 'authors' for short
People on the Keyman core team creating Keyman products.
People using Keyman Engine to build apps, people working with Keyman APIs online, using schemas.
People who use Keyman on their device to type, that is: Keyman for Windows, Keyman for macOS, Keyman for Linux, Keyman for Android, Keyman for iOS, KeymanWeb users. 'End users' in full, 'users' for short
The existing text in the Text Store that immediately precedes the insertion point. The context can impact what text will be produced by the next keystroke.
For example, a user is editing a document containing the text "abc123", and the user has clicked between the letters b and c so that the insertion point is after the second character in the document. The context in this scenario would be simply "ab".
Note that the context is not the entire text preceding the insertion point, but just a window that moves with the insertion point, for performance reasons. In Keyman Core, currently this window is 80 characters wide.
The application that is receiving and applying the text input. The application could be a word processor or a browser or the system settings app -- any application that supports text input.
A Client Application which implements system APIs for making the Text Store available, and where Engine can manipulate the Text Store directly without resorting to pushing keystrokes such as Backspace to the application.
(Or Dead Key, shorthand dk) On a keyboard, a key that does not produce text output on its own but impacts the text produced by the next keystroke.
For example, if the apostrophe key is defined as a dead key, then typing the apostrophe followed by the letter e, could produce the output é.
In Keyman keyboard language, the deadkey statement represents a marker, and is Keyman's implementation for supporting deadkeys.
See Marker
A software component that is invoked by the operating system to support text input. An input method may support a single language and a single script, or it may support many scripts and languages with a single input method as Keyman does.
(Or Virtual Key Code) The value used by the operating system to identify the physical key that was pressed.
For example, Microsoft Windows identifies the S key with key code 0x53 and macOS identifies the S key with key code 0x01.
Several discrete things are referred to as a keyboards. In the context of Keyman, 'keyboard' often refers to the Keyman Keyboard, a dynamic keyboard implemented in software and designed to support text input for one or more scripts.
Keyboard may also mean:
- Physical Keyboard - the hardware keyboard used for text input with a computer
- On-screen Keyboard - or OSK, a keyboard displayed graphically which represents the layout of the keys on the physical keyboard and what characters they will produce
- Touch Keyboard - the keyboard displayed for text input on a mobile device with a touchscreen such as a smartphone or tablet
Keyboard Processors within Core act as the primary interfaces and objects for processing Keyman keyboard rules. Within Core, there are multiple types - one for .kmn keyboards, one for LDML XML keyboards, and a mock variant for unit tests.
Keyboard Processors are designed to be platform independent and are completely stateless. Their only role is to transform preprocessed input events, given a Context and state token, into a set of 'actions' in response. Their primary process_event function is idempotent.
Keyboard Processors implement the km::core::abstract_processor class in Keyman Core.
Note: the Web Engine currently implements a legacy keyboard processor, but as of 17.0, all other engines have removed the legacy keyboard processors.
The User Interface integration, e.g. keyboard install, config dialog, etc, that end users install, and contains the Engine and everything else, for a given platform, e.g. Keyman for Windows, Keyman for Android, etc. Also known as Keyman App.
The km_core_ set of functions, platform agnostic, which contains Keyboard Processors and liaises between Engine and Keyboard Processor to manage context and actions.
A consumer of Keyman Core's functionality, providing platform-level integration. This will be bundled inside a Keyman Application
A software component that accepts incoming keystrokes and produces text output appropriate to a certain script. A Keyman Keyboard is built using Keyman Developer and contains rules that determine what text to output for a given keystroke and context.
A data structure that represents the words in use for a language and their relative frequency of occurrence. A lexical model is required to support predictive text for a given language.
See also Deadkey.
A positional token in cached context and which is output from keyboard rules, that stores transient state, but which is not emitted as a character to the document. In the cached context, markers are conceptually stored between characters. Multiple markers can be inserted between a character pair, and those markers are ordered as well.
A Client Application which does not make the Text Store directly available, so Engine must emit output characters and keystrokes through system-level keyboarding APIs, to simulate the behaviour of a Compliant Client Application. Typically this includes emitting backspace keystrokes to delete characters from context. Importantly, as Engine cannot read the Context from the Text Store, Core maintains a cached context which is lost whenever the user moves the insertion point.
A keyboard feature that attempts to predict what words the user is typing, offering suggestions as the user types and also corrections in case the user has misspelled a word. To implement predictive text for a given language, a lexical model is required.
The key code emitted by a hardware keyboard, usually translated to a Key Code by the operating system. For example, S on a US ANSI keyboard has scan code 32. The codes tend to be numbered roughly from top-left of the keyboard, for common scan code mappings. Scan Codes are not usually the same as Key Codes.
The entire text of the document, where the Context is just the segment preceding the insertion point.
See Key Code