Standardize all dialogs: native (wx.MessageDialog) or web (existing accessible WebView) — kill hand-rolled custom dialogs; fixes onboarding crash + #72

[taylorarndt]

Product area

UI / dialogs, accessibility, onboarding

Severity

P1 — a startup crash plus inconsistent, hand-rolled dialogs

Summary

Quill has ~15 dialog classes and 39 raw wx.Dialog(...) usages across 8 UI files. Many are hand-rolled custom dialogs with their own focus, keyboard, and button handling — which is where bugs keep appearing (focus landing on the wrong control, buttons that don't behave, and at least one startup crash). We should standardize on two dialog kinds and delete the bespoke ones:

• Native (wx.MessageDialog / wx.MessageBox) for confirms, saves, and simple messages. Reliable button handling, read directly by VoiceOver/NVDA.
• Web (the existing wx-accessible-webview surfaces) for anything that displays rich content or captures input. Reuse what we already ship — AccessibleChatView is the web-input pattern (the Ask Quill chat), AccessibleHtmlDialog for display, MarkdownPreviewDialog for previews. No new component needed.

Bugs this fixes / folds in

• Startup crash: on a fresh profile, after the "Ready. Tip: press Ctrl+Shift+P" status is announced, the first-run onboarding sequence crashes (reported on both Windows and macOS, with a screen reader active). The crash is almost certainly in one of the hand-rolled onboarding dialogs (show_startup_wizard_page → profile/assistant/speech/watch-folder prompts). Converting these removes the crasher.
• [Bug]: the last step of onboarding opens a raw html file. #72 — the last onboarding step opens a raw HTML document in an editor tab (open_welcome_guide puts HTML/markdown straight into a Document). It should render in a web surface instead. This issue supersedes [Bug]: the last step of onboarding opens a raw html file. #72.
• Sticky-note editor focus lands on Save instead of the text field; it should be a web form (title + body) following the chat pattern.

Dialog inventory & target

Keep (already correct): AskQuillChatDialog (web chat), MarkdownPreviewDialog (web), unsaved-changes prompt (now native wx.MessageDialog), delete-note confirm (native).

→ Web (display or input):

• StickyNoteEditorDialog, StickyNotesVaultDialog (quill/ui/sticky_notes.py)
• RunPythonDialog, PromptStudioDialog, AgentCenterDialog, WritingAssistantDialog, SearchableModelPickerDialog, AIHubDialog, AssistantConnectionDialog (quill/ui/assistant_tools.py)
• AIModelDialog (quill/ui/ai_model_panel.py), TrainStyleDialog (quill/ui/style_panel.py)
• onboarding/welcome (render, don't dump raw HTML)

→ Native wx.MessageDialog: trust-consent prompt, untrusted-location, and the assorted confirm prompts in quill/ui/main_frame.py.

Decide case-by-case: CommandPaletteDialog (search + list picker) — likely web for consistent screen-reader behavior.

Acceptance

• No hand-rolled wx.Dialog subclasses remain for confirm/message flows; those use wx.MessageDialog/MessageBox.
• Input/display dialogs use the existing accessible web surfaces (chat/html/preview) — reusing AccessibleChatView, not a new component.
• First-run onboarding completes without crashing on Windows and macOS with a screen reader on.
• [Bug]: the last step of onboarding opens a raw html file. #72: welcome/onboarding content renders, not raw HTML.

[taylorarndt]

Progress — @taylorarndt is actively working this

Approach (settled): every dialog becomes one of two kinds, no hand-rolled custom dialogs:

• Web for display + input — reuse the existing AccessibleWebView (the same accessible WebView the Ask Quill chat already uses), via its JS→Python on_message bridge. No new component.
• Native wx.MessageDialog / wx.MessageBox for confirms, saves, and simple messages.

Done

• ✅ Startup is crash-proof (0bc14ca): first-run/onboarding steps are isolated; an exception is logged to logs/startup-errors.log and Quill stays open instead of dying silently after the startup tip.
• ✅ Sticky-note editor → web form (ffe0864): real labelled Title + Note fields, focus lands on Title (fixes the focus bug), Save/Cancel over the JS bridge, native fallback if no WebView. Note model unchanged.

In progress / next

• Onboarding hand-rolled dialogs (assistant/speech/watch-folder) → web form / native.
• Assistant tools: Prompt Studio, Agent Center, Writing Assistant, model pickers, AI Hub, Run Python → web.
• AIModelDialog, TrainStyleDialog → web.
• Confirm/message prompts in main_frame.py → native wx.MessageDialog.
• Welcome/onboarding render (closes [Bug]: the last step of onboarding opens a raw html file. #72) instead of raw HTML.

Converting + committing in verified increments on main.

[taylorarndt]

Assessment after reading the code: forms vs interactive tools

Converting dialogs splits into two very different efforts:

Submit-once forms — easy, safe, use show_web_form (DONE):

• ✅ Sticky-note editor (ffe0864)
• ✅ Writing Assistant onboarding (06c18ee)

Interactive tools — NOT forms. Each has live lists, generate/preview/verify buttons, async downloads or background build threads, chat logs. Converting each to web is a per-dialog interactive rebuild (bidirectional JS↔Python), and each is a working feature:

• RunPythonDialog, PromptStudioDialog, AgentCenterDialog, WritingAssistantDialog,
  AIHubDialog, AssistantConnectionDialog, TrainStyleDialog, AIModelDialog, CommandPaletteDialog

These are accessible native wx today (labelled fields/lists), not the broken hand-rolled kind. Recommendation: convert these individually, each tested with a screen reader, rather than a batch rewrite that risks regressing working AI features. Prioritize by which ones actually read poorly.

Confirm/message prompts → native wx.MessageDialog (mechanical, safe) — can be done in a sweep.

Still pure-form & safe to convert next: remaining first-run onboarding (speech, watch-folder), welcome render (closes #72).