silverstein/minutes

Environment minutes-cli version: 0.23.0 OS: Windows 11 (build 10.0.26200) GPU: NVIDIA GeForce GTX 1050 (Pascal, compute capability 6.1 / sm_61) CMake: 4.4 Build tool: Ninja 1.13.2 (also reproduced with the default Visual Studio generator) MSVC toolsets tested: 14.51.36231 (VS "18" 2026 Build Tools) and 14.44.35207 (VS2022 Build Tools) CUDA Toolkits tested: 13.3, 12.6, 11.8 (all via NVIDIA's official Windows local installers) Summary Compiling minutes-cli with --features cuda on Windows fails for every CUDA Toolkit version that still supports Pascal (compute_61): CUDA 13.3: nvcc fatal: Unsupported gpu architecture 'compute_61' — expected, since NVIDIA dropped Pascal support in CUDA 13.x. Not a minutes-cli bug, just confirms 13.x can't be used for this GPU generation. CUDA 12.6 (the last version with full Pascal support): the build crashes during CMake's own compiler-identification step — nvcc error: 'cudafe++' died with status 0xC0000005 (ACCESS_VIOLATION) while compiling CMak

Context First, a bit of background: I'm a Windows contributor who's been using Minutes as an end user. The app is genuinely excellent — the pipeline from recording to structured markdown is smooth, and the MCP integration is thoughtful. This is a "thinking out loud" proposal, not a complaint. Happy to hear why the current approach is the right one. The current experience for non-developers When a user opens the Recall panel, they're greeted by a full xterm.js terminal running Claude Code. As a developer I can appreciate the elegance — the assistant workspace is a real directory with CLAUDE.md + CURRENT_MEETING.md, the MCP tools feed live context, skills auto-sync. It's a well-engineered system. But for a non-technical user (or even a technical user who just wants to ask "what did we decide about the budget?"), the experience is jarring: The terminal appearance signals "developer tool" rather than "meeting assistant" The user needs to know what to type and how to interact with a C

Context From Discussion #44 with @Dieterbe. On Wayland, apps cannot register global hotkeys. The compositor owns global keybindings. The current settings dialog shows a keyboard shortcut picker that won't work on Wayland. What needs to happen Detect Wayland at runtime (check WAYLAND_DISPLAY or XDG_SESSION_TYPE env vars) Replace shortcut picker on Wayland with instructions: Show that minutes toggle-recording and minutes toggle-dictation CLI commands exist Link to documentation for binding these in common compositors (Hyprland bind, GNOME Settings, KDE Shortcuts) Keep the shortcut picker on macOS and X11 where global hotkeys work natively Example compositor config # Hyprland example bind = SUPER, R, exec, minutes toggle-recording bind = SUPER, D, exec, minutes toggle-dictation Relevant code crates/core/src/hotkey_macos.rs - macOS-specific CGEventTap implementation Tauri settings dialog UI Related: Discussion #44

Context From Discussion #44 with @Dieterbe. The Tauri desktop app settings dialog has two UX issues on Linux: Section organization: Settings appear as one long undifferentiated sequence. Needs clearer visual grouping (headers, dividers, or collapsible sections). White widgets on dark theme: Some native form inputs (likely WebKitGTK-rendered) don't respect the dark mode context, appearing white against a dark background. Screenshots See Discussion #44 for screenshots from Arch Linux / Wayland / Hyprland. What needs to happen Add visual section groupings to the settings dialog (Recording, Transcription, Shortcuts, etc.) Override native form input styles with explicit CSS for the dark theme on Linux/WebKitGTK Test on both dark and light themes Relevant code tauri/ directory contains the desktop app Settings dialog UI components This is a good first contribution since it's visual, self-contained, and doesn't require understanding the audio pipeline. Related: Discussion #44