Profiles

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.

📸 Screenshot needed: The Profiles page in full, showing the profile list, the enable/disable toggles, the rule-matching fields, and the live-context view.

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

📸 Screenshot needed: The profile editor open on a single profile, showing the process/app match field, URL pattern field, priority field, and the override controls (language, task, translation, model, whisper mode, prompt action).

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

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.

📸 Screenshot needed: The live-context view showing the currently focused process name and detected URL.

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.

📸 Screenshot needed: The Profiles section showing the Install Window Calls extension and Enable browser URL detection buttons.

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.

📸 Screenshot needed: A live diagnostic banner on the Profiles page reporting failed window or URL detection, with its one-click remediation button.

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

• Prompts & AI actions — the prompt actions a profile can bind as an override.
• Wayland notes — full setup for window providers and browser URL detection.

---

Changelog

Date	Change
2026-06-17	Initial version.