This document describes the settings and configuration UI in Hyprnote, including the onboarding flow, permission requests, and user configuration interface. The system guides new users through initial setup via a dedicated onboarding window, then provides ongoing access to settings through the main application. The configuration system manages general preferences (language, jargons, templates), notification settings, and AI enhancement parameters. For the underlying configuration data model and persistence, see page 7.2. For model management UI, see pages 5.2 and 4.4.
The onboarding process guides new users through initial setup in a dedicated window. The flow is controlled by the OnboardingNeeded2 flag stored in the desktop store.
Diagram: Onboarding Flow Architecture
Sources: apps/desktop/src/routes/app/onboarding/index.tsx1-98 apps/desktop/src-tauri/src/ext.rs1-33 apps/desktop/src-tauri/src/commands.rs45-60
The OnboardingNeeded2 flag is stored in the persistent desktop store via tauri-plugin-store2. The AppExt trait apps/desktop/src-tauri/src/ext.rs3-32 provides helper methods:
desktop_store(): Retrieves the scoped store for desktop settingsget_onboarding_needed(): Reads the OnboardingNeeded2 flag (defaults to true)set_onboarding_needed(v): Updates the flag to persist onboarding completionThe StoreKey enum apps/desktop/src-tauri/src/store.rs4-6 defines the typed key:
The onboarding route apps/desktop/src/routes/app/onboarding/index.tsx22-25 is defined at /app/onboarding with step-based navigation:
The STEPS constant apps/desktop/src/routes/app/onboarding/index.tsx13 defines the flow: ["welcome", "permissions"].
The useOnboarding hook apps/desktop/src/routes/app/onboarding/index.tsx51-97 manages navigation:
| Property | Type | Purpose |
|---|---|---|
step | "welcome" | "permissions" | Current step in flow |
local | boolean | Whether onboarding is local-only (no cloud sync) |
previous | string | undefined | Previous step for back navigation |
next | string | undefined | Next step, or undefined if complete |
goNext | OnboardingNext | Advances to next step or completes onboarding |
goPrevious | () => void | Returns to previous step |
When the flow completes apps/desktop/src/routes/app/onboarding/index.tsx71-79:
commands.setOnboardingNeeded(false) to persist completionwindowsCommands.windowShow({ type: "main" })windowsCommands.windowDestroy({ type: "onboarding" })Sources: apps/desktop/src/routes/app/onboarding/index.tsx1-98 apps/desktop/src-tauri/src/ext.rs16-31 apps/desktop/src-tauri/src/store.rs3-9
The permissions step apps/desktop/src/components/onboarding/permissions.tsx1-138 requests three system permissions required for audio capture and meeting detection.
Diagram: Permission Request Flow
Sources: apps/desktop/src/components/onboarding/permissions.tsx1-138
The PermissionBlock component apps/desktop/src/components/onboarding/permissions.tsx9-65 renders individual permission requests:
Each block displays:
The component requests three permissions apps/desktop/src/components/onboarding/permissions.tsx92-124:
| Permission | Purpose | Authorized Message | Unauthorized Message |
|---|---|---|---|
| Microphone | Capture user's voice | "Good to go :)" | "To capture your voice" |
| System Audio | Capture speaker output | "Good to go :)" | "To capture what other people are saying" |
| Accessibility | Sync mic inputs & mute detection | "Good to go :)" | "To sync mic inputs & mute from meetings" |
The continue button apps/desktop/src/components/onboarding/permissions.tsx126-135 is only enabled when all three permissions are granted:
The button text changes based on state:
Sources: apps/desktop/src/components/onboarding/permissions.tsx71-137
The configuration system uses three structures persisted in the user database. For detailed configuration model documentation, see page 7.2.
Diagram: Configuration Structure
Sources: crates/db-user/src/config_types.rs1-108
The Config struct crates/db-user/src/config_types.rs4-11 organizes settings into three categories:
Sources: crates/db-user/src/config_types.rs4-96
The settings interface organizes configuration options into multiple views accessible through a tabbed or sectioned navigation pattern.
Diagram: Settings UI Architecture
Sources: apps/desktop/src/routeTree.gen.ts38-80 crates/db-user/src/config_types.rs1-108 plugins/db/src/commands/calendars.rs1-78 crates/db-user/src/calendars_ops.rs121-141
Based on the configuration model and database operations, the settings UI organizes into these views:
General Settings View (ConfigGeneral):
Calendar Settings View:
toggle_calendar_selected() crates/db-user/src/calendars_ops.rs121-141before field)auto field)ignored_platforms)Feedback View:
Help & Support View:
Sources: crates/db-user/src/config_types.rs35-107 crates/db-user/src/calendars_ops.rs4-141 plugins/db/src/commands/calendars.rs1-78
The calendar settings interact with the calendar database operations through the DB plugin. The Calendar type crates/db-user/src/calendars_types.rs4-13 includes:
| Field | Type | Purpose |
|---|---|---|
id | String | Unique identifier |
tracking_id | String | Platform-specific ID |
user_id | String | Owner user ID |
platform | Platform | Apple, Google, or Outlook |
name | String | Calendar display name |
selected | bool | Whether calendar is monitored |
source | Option<String> | Calendar source metadata |
The UI fetches calendars via list_calendars() plugins/db/src/commands/calendars.rs24-37 and toggles selection via toggle_calendar_selected() plugins/db/src/commands/calendars.rs62-77 which flips the selected boolean atomically crates/db-user/src/calendars_ops.rs121-141
Sources: crates/db-user/src/calendars_types.rs3-26 plugins/db/src/commands/calendars.rs1-78 crates/db-user/src/calendars_ops.rs121-141
The system distinguishes between three language settings that control different aspects of the application:
Diagram: Language Settings Usage
Sources: crates/db-user/src/config_types.rs38-51
display_language): Controls UI text throughout the applicationspoken_languages): Array of languages for STT recognition during transcriptionsummary_language): Target language for AI-generated enhanced notesThe hypr_language::Language type is serialized as a string with ISO 639 validation crates/db-user/src/config_types.rs38-39:
The jargons field crates/db-user/src/config_types.rs44 stores custom vocabulary for transcription correction. During enhancement, jargons are injected into the LLM prompt to correct technical terms and proper nouns.
Sources: crates/db-user/src/config_types.rs35-68
The ConfigAI struct crates/db-user/src/config_types.rs90-96 controls AI enhancement behavior:
The ai_specificity field crates/db-user/src/config_types.rs93 controls LLM enhancement aggressiveness with four levels:
| Level | Creativity | Behavior |
|---|---|---|
| 1 | Low | Minimal changes, fix typos, preserve structure |
| 2 | Moderate | Minor enhancements, add relevant details |
| 3 | High (default) | Significant enhancement, incorporate transcript fully |
| 4 | Very High | Extensive restructuring, professional polish |
The setting is rendered as a slider in the UI and also controls header adherence when users provide custom note structures.
The AI settings also include crates/db-user/src/config_types.rs91-92:
api_base: Optional custom LLM endpoint URL (for using cloud providers instead of local inference)api_key: Optional API key for authenticated cloud services (stored securely, masked in UI)The redemption_time_ms field crates/db-user/src/config_types.rs94 sets the grace period (in milliseconds) after transcription completion before automatic AI enhancement triggers. Default is 500ms, allowing users to quickly edit transcripts before enhancement.
Sources: crates/db-user/src/config_types.rs89-107
The settings UI persists configuration through the DB plugin, which exposes user database operations as type-safe Tauri commands.
Diagram: Configuration Persistence Flow
Sources: plugins/db/src/lib.rs1-103 crates/db-user/src/config_types.rs1-108 crates/db-user/src/config_ops.rs1-145
While the specific get_config and update_config commands aren't shown in the provided files, the DB plugin follows the established pattern seen in calendar commands plugins/db/src/commands/calendars.rs1-78 Commands are:
#[tauri::command] and #[specta::specta] for type generationstate: tauri::State<'_, crate::ManagedState> for database accessResult<T, String> for type-safe error handlingUserDatabase methods in the hypr-db-user crateThe Config struct crates/db-user/src/config_types.rs4-11 is persisted in the config table with JSON columns for each sub-configuration:
The from_row method crates/db-user/src/config_types.rs14-32 deserializes JSON columns:
This pattern allows atomic updates of configuration subsections while maintaining type safety through serde.
Sources: crates/db-user/src/config_types.rs1-108 plugins/db/src/commands/calendars.rs1-78
Settings and onboarding commands use tauri-specta for automatic TypeScript binding generation.
Diagram: Type-Safe Command Interface
Sources: plugins/windows/src/lib.rs41-59 apps/desktop/src/types/tauri.gen.ts1-108
The onboarding state commands apps/desktop/src-tauri/src/commands.rs45-60 demonstrate the pattern:
These generate TypeScript bindings with exhaustive error handling:
The frontend can safely discriminate success/error cases:
Sources: apps/desktop/src-tauri/src/commands.rs45-60 apps/desktop/src/types/tauri.gen.ts10-34
The Settings window is managed through the Windows plugin's AppWindow enum as AppWindow::Settings. The window lifecycle follows the standard pattern defined in the Windows plugin.
Diagram: Settings Window Lifecycle
Sources: plugins/windows/src/ext.rs72-110 plugins/windows/src/lib.rs22-39 apps/desktop/src/routeTree.gen.ts68-80
The Settings window is shown via the window_show command plugins/windows/src/commands.rs5-11:
From the frontend, this is called as plugins/windows/js/bindings.gen.ts10-17:
When the window doesn't exist, the WindowImpl trait's show() method plugins/windows/src/ext.rs72-110 creates it via build_window(), then shows and focuses it. If it already exists, it's simply brought to focus.
Sources: plugins/windows/src/commands.rs3-11 plugins/windows/src/ext.rs72-110 plugins/windows/js/bindings.gen.ts9-17
The settings interface uses nested routing apps/desktop/src/routeTree.gen.ts38-80:
| Route Path | Route ID | Purpose |
|---|---|---|
/app/settings | /app/settings | Parent route container |
/app/settings/_layout | /app/settings/_layout | Layout wrapper with navigation |
/app/settings/ | /app/settings/_layout/ | Default settings view (index) |
The _layout pattern wraps the settings content with consistent navigation UI (tabs/sidebar) while the index route renders the default settings panel.
Sources: apps/desktop/src/routeTree.gen.ts38-80 apps/desktop/src/routeTree.gen.ts226-253
Each configuration struct implements the Default trait, providing sensible initial values:
crates/db-user/src/config_types.rs55-68
autostart: false - User must opt-in to autostartdisplay_language: "en" - English UIspoken_languages: ["en"] - English-only transcriptionsummary_language: "en" - English outputjargons: [] - No custom vocabularytelemetry_consent: true - Analytics enabled by defaultsave_recordings: Some(false) - Audio not saved for privacyselected_template_id: None - No default templatecrates/db-user/src/config_types.rs79-87
before: true - Show pre-meeting notificationsauto: true - Auto-record enabledignored_platforms: None - Monitor all calendarscrates/db-user/src/config_types.rs98-107
api_base: None - Use local LLMapi_key: None - No cloud API keyai_specificity: Some(3) - Flexible/high creativity moderedemption_time_ms: Some(500) - 500ms edit grace periodThese defaults balance functionality with privacy, enabling core features while requiring explicit opt-in for more intrusive capabilities like autostart and audio recording storage.
Sources: crates/db-user/src/config_types.rs55-107
The configuration system enforces type safety across language boundaries:
Fields with complex types use specta annotations for TypeScript generation crates/db-user/src/config_types.rs37-51:
This ensures:
The user_common_derives! macro crates/db-user/src/config_types.rs3 applies:
serde::Serialize and serde::Deserialize for JSON encodingspecta::Type for TypeScript type generationschemars::JsonSchema for JSON schema validationThis tri-fold type safety ensures configuration remains consistent from database storage through IPC to frontend display.
For more on type safety infrastructure, see Type Safety and Code Generation.
Refresh this wiki
This wiki was recently refreshed. Please wait 6 days to refresh again.