Skip to content

Profiles

Chris Smashe edited this page Jun 17, 2026 · 4 revisions

Profiles

Profiles let TypeWhisper apply different settings automatically based on the active application or the URL pattern of the focused browser tab. When a profile's rules match the context you are dictating into, its overrides take effect for that dictation.

The Profiles page: the profile list with enable toggles, the Enable browser URL detection banner, and the rule-matching fields (Apps and URL patterns)

What profiles do

A profile is a set of matching rules plus a set of overrides. When you dictate, TypeWhisper looks at what application (and, where available, what URL) has focus, finds the highest-priority enabled profile whose rules match, and applies that profile's overrides for the dictation.

In the Linux branch, profiles support:

  • Create, edit, enable/disable, save, and delete
  • Process/app matching fields
  • URL pattern fields
  • Priority
  • Overrides for language, task, translation, model, whisper mode, and prompt action
  • A live-context view for checking what app context TypeWhisper sees

The profile override controls: Task, Translation, Model, Prompt Action, Whisper Mode, and Style Preset

Matching rules

Rule type What it matches
Process / app The process name of the focused window (for example firefox, code, soffice.bin).
URL pattern The address of the focused browser tab (for example mail.google.com, *.github.com).
Priority When more than one enabled profile matches, the higher priority wins.

Overrides

When a profile matches, it can override any of these for the dictation:

Override Effect
Language Transcribe in a specific language for this context.
Task transcribe or translate.
Translation Target language for translation.
Model Use a different transcription model for this app.
Whisper mode Optimize for quiet/whispered speech in this context.
Prompt action Run a specific [[Prompts & AI actions

Additional per-profile controls: Cleanup Override, Developer Formatting Override, Priority, a per-profile Profile Hotkey, and the Activation toggle

Live-context view

The Profiles page includes a live-context view that shows what app context TypeWhisper currently sees — the focused process and, where available, the detected URL. Use it to confirm that your matching rules will fire against the apps you care about before you rely on them.

The Live Context dialog: the matched profile (or "No active match"), the Current App, the Current Domain / detected URL, and a "Use current app" button

Example uses

  • Use a specific language for one editor or browser.
  • Enable whisper mode for a quiet-room workflow.
  • Use a different transcription model for one app.
  • Run a specific prompt action for text captured in a matching context.

Wayland prerequisites

On Wayland, profile matching needs extra setup because the compositor restricts what an unprivileged app can learn about the focused window and browser. See Wayland notes for the full setup.

App-name rules

App-name (process) rules need a compositor-native window provider so TypeWhisper can learn which window has focus:

Compositor Window provider
Hyprland hyprctl (installed by default)
Sway swaymsg (installed by default)
KDE Plasma kdotool (install separately — without it, app-name matching is unavailable in that session)
GNOME The user-installed Window Calls GNOME Shell extension

On GNOME, the Profiles section has an Install Window Calls extension button that opens the extension page when the extension is missing. Without it, GNOME Wayland users can still use URL-only profile rules and any global (no-match) profile, but app-name matching will not fire.

URL-pattern rules

URL-pattern rules need browser-side AT-SPI accessibility enabled. The Profiles section has an Enable browser URL detection button that patches the relevant launchers and writes the environment file. Firefox additionally needs the accessibility.force_disabled flip in about:config (set it from 0 to -1, then restart Firefox). See Wayland notes for the complete walkthrough.

Diagnostics

When window detection or URL detection fails repeatedly, the Profiles section shows live diagnostic banners explaining what is missing, with a one-click remediation button for the missing piece.

The Error Log on the About page records a per-state walk diagnostic that pinpoints exactly which step failed. For URL detection, look for entries like:

AT-SPI URL walk: process=firefox matched-app='Firefox' nodes-walked=N best-score=... result=...
  • matched-app=none means the browser is not exposing AT-SPI.
  • result=null with a non-null best-score means the walker reached the address bar but did not recognise it.

Related pages


Changelog

Date Change
2026-06-17 Initial version.
2026-06-17 Added Profiles screenshots (list, overrides, advanced, live context).
2026-06-17 Removed unused screenshot placeholders.

Clone this wiki locally