Dasher for GTK

Dasher is an information-efficient text-entry interface, driven by continuous pointing gestures. It lets you write using eye gaze, a mouse, a switch, a joystick, or touch — designed for accessibility and augmentative communication (AAC).

This is the GTK frontend, built on the shared DasherCore engine.

dasher.at — downloads, user docs, and live demo Feature status — what each platform supports All repos — engine, frontends, design guide

Status

In development — early-stage GTK4 frontend aiming to replace Dasher 5. See the feature matrix for what's implemented.

Install

Not yet publicly available — build from source (see below), or grab an artifact from Releases.

Build

Prerequisites

Platform	Command
macOS	brew install gtk4 gtkmm4 pkg-config cmake
Linux (Debian/Ubuntu)	apt-get install build-essential libgtk-4-dev libgtkmm-4.0-dev git cmake pkg-config libspeechd-dev libclang-dev
Windows	Install GTK from GVSBuild to C:\gtk, add C:\gtk\bin to PATH. Requires CMake, Git, and MSVC or Clang. Use an optimized release build for binary compatibility.

All platforms additionally require a Rust toolchain (cargo) to build the bundled rust-tts-wrapper. Install it from rustup.rs. On Linux the system TTS feature binds speech-dispatcher via bindgen, hence libspeechd-dev (headers) and libclang-dev (for bindgen) above.

Steps

git clone --recursive https://github.com/dasher-project/Dasher-GTK.git
cd Dasher-GTK
mkdir build && cd build
cmake ..
cmake --build . --config Release --parallel

The binary and all runtime files are placed in build/Dasher/.

Running

Dasher must be launched from the build/Dasher/ directory so it can find its data files:

cd build/Dasher
./Dasher

Running the Tests

Lightweight unit tests live in tests/ and build alongside the app; doctest is fetched automatically at configure time, so no extra dependency is required. After configuring and building, run the suite with ctest:

ctest --test-dir build --output-on-failure

CI runs these tests on every push as part of the multi-platform workflow.

TTS Support

The rust-tts-wrapper submodule provides text-to-speech support. It is included automatically when cloning with --recursive. CMake builds and links it if the submodule is present.

• macOS: builds with avsynth,cloud features (no local speech-dispatcher needed)
• Linux: builds with system,cloud features (uses speech-dispatcher + cloud engines); needs libspeechd-dev and libclang-dev (see Prerequisites)
• Windows: builds with sapi,cloud features (uses the Windows SAPI engine plus cloud engines)
• All platforms need a Rust toolchain (cargo) on PATH to compile the wrapper

Runtime Data Files

The CMake build copies data files into build/Dasher/Data/. The directory layout after building:

build/Dasher/
├── Dasher              # executable
├── libdasher.dylib     # macOS (libdasher.so on Linux, dasher.dll on Windows)
├── UIStyle.css
├── Data/
│   ├── alphabet.*.xml  # alphabet definitions
│   ├── color*.xml      # colour schemes
│   └── training*.txt   # language model training data (PPM)
├── Strings/
│   └── strings_*.json  # UI translations
└── Resources/
    └── License/

Dasher uses a PPM (Prediction by Partial Match) language model trained on text files. Each alphabet definition specifies a trainingFilename (e.g. training_english_GB.txt). Without training data, all letter boxes will be the same size and prediction will not work. Training files are copied from DasherCore/Data/training/ during the build; if letters appear uniformly sized after launch, run from build/Dasher/ so the "Data" relative path resolves, and rebuild if stale (cmake --build build).

Known Issues

• bad_variant_access warnings on startup are non-fatal. The GTK UI queries some CAPI parameters with the wrong getter type (string vs long); these do not affect functionality.

Architecture

This frontend consumes DasherCore through its C API (src/Engine/DasherBridge.cpp, backed by dasher.h). DasherBridge owns the engine handle, feeds it GTK pointer input, and receives draw commands that RenderingCanvas renders onto a GTK widget. InputManager/DwellClickHandler translate raw input, and TtsService / DirectModeService handle output and spoken feedback.

flowchart LR
    Input["GTK pointer / keys"] --> InputMgmt["InputManager<br/>DwellClickHandler"]
    InputMgmt --> Bridge["DasherBridge"]
    Bridge <-->|"C API (dasher.h)"| Core[("DasherCore<br/>engine")]
    Core -.->|"draw commands"| Canvas["RenderingCanvas"]
    Bridge --> Output["TtsService<br/>DirectModeService"]

Loading

See DasherCore's C API for the engine contract.

Repository layout

Path	Purpose
src/Engine/	DasherBridge + CommandRenderer: C API bridge to DasherCore
src/Input/	InputManager, DwellClickHandler (pointer/switch input)
src/Output/	TtsService, DirectModeService (speech + output modes)
src/Preferences/	Settings UI (PreferencesWindow, SettingsSection)
src/UIComponents/	Reusable GTK widgets (canvas, synced controls)
tests/	doctest unit tests
DasherCore/	DasherCore submodule (do not edit here — PR upstream)
rust-tts-wrapper/	TTS wrapper submodule
Thirdparty/SDL	SDL submodule (joystick input)

Contributing

See CONTRIBUTING.md for build details, code style, and DCO sign-off. For project-wide conventions (code of conduct, RFCs, security), see the org contributing guide.

Please file bug reports in the issues of this repository. To join the development group, send a pull request or reach us via Slack (OpenAAC).

License

MIT — see LICENSE.