Brokentooth.io / 02 Projects / OmniBoard

OmniBoard

An Android keyboard built around terminals, touch geometry, and the stubborn realities of typing.

I want a phone keyboard that is useful after I open a terminal. That sounds like a modest request until a keyboard decides a command flag would look better as an ordinary English word.

OmniBoard is my Android keyboard project, built from FlorisBoard. The work covers layouts, terminal controls, touch geometry and autocorrect. Those are connected problems, but they are not interchangeable. A better dictionary cannot repair an input path that never asks the dictionary anything.

The correction that never gets considered

A retrospective report on the typing harvest found that many of the studied surviving typos occurred on surfaces where the correction engine was not invoked. That changes where the debugging has to start. Before asking whether the right candidate ranked highly enough, I need to know whether candidate generation happened at all.

Raw terminal input is a particular complication. The usual composing-region behaviour is not available in the same way as a conventional text field. The implementation at commit a47aa0117 adds internal word and line buffers, rawWord and rawLine, so the keyboard can track input without depending entirely on the editor's composing state.

That path evaluates candidate corrections and can apply a replacement at a word boundary. It also checks for signs of technical input: command prefixes, flags, paths, digits and shell metacharacters. Those checks are conservative heuristics. They do not understand an arbitrary shell command, and I would rather say that plainly than dress a collection of pattern checks up as a parser.

Where it stands

The source establishes that the tracking and filtering mechanisms were implemented. It does not establish that every terminal handles replacement and cursor position correctly on a physical device. That is a separate validation problem.

The broader project is still active. Layout controls and touch behaviour matter alongside the correction engine; the goal is a keyboard that accommodates technical work without making ordinary writing miserable. A clever model is useful. Being called at the right time is rather more fundamental.

More from OmniBoard

  1. 01 From Typing and Speech to Training DataThe unglamorous collection and cleanup between an interaction and a model. In development#omniboard#soma#data-pipeline#keyboard#speech
  2. 02 When Autocorrect Never RunsA typing-model problem that turned out not to be a typing-model problem. Research note#omniboard#keyboard#software#debugging