Future Qt desktop experience — what should feel genuinely native rather than merely “the web app in another window”?

[qnbs]

Why this exists

Issue #332 and the binding native roadmap describe a future Qt-first desktop product built around Qt Quick/QML and the authoritative Rust Core. This Discussion explores what should feel genuinely native rather than merely placing the web application in another window.

Product decision space

Consider native menus and shortcuts, window and session behavior, multi-window and multi-project handling, OS Open/Save dialogs, drag and drop, recent documents, system theme and high-contrast integration, accessibility APIs, startup and input behavior, background resume, and large-project responsiveness.

Native notifications or a tray integration should exist only where they solve a real workflow problem. Updater UX, recovery, progress, and restart behavior should be understandable and safe. Platform-specific polish is welcome when it does not create semantic divergence: the same project authority, persistence rules, accessibility intent, and user-visible data semantics should remain shared.

The Qt product should use Qt Quick/QML with a thin bridge to the Rust Core. This is not a proposal to recreate the product with Qt WebEngine. The PWA should remain better at zero-install reach, rapid safe updates, portability, and browser-native capabilities where those are genuinely stronger.

Role perspectives

Role-perspective note: The viewpoints below are maintainer-curated, AI-assisted design lenses. They are not separate community members, votes, user testimony, or evidence of consensus.

• 🐧 Linux writer: reliable files, windows, shortcuts, themes, accessibility, and predictable desktop integration.
• 🍎 macOS writer: native menus, document sessions, safe updates, typography, and platform conventions.
• 🪟 Windows writer: file dialogs, recent documents, keyboard workflows, notifications, and system integration.
• ♿ Native accessibility: platform accessibility APIs, focus, high contrast, screen readers, and consistent semantics.
• ⚡ Performance/low-end hardware: startup, input latency, memory, large projects, and background behavior.
• 🧭 Architecture/maintainer: renderer-neutral authority, bounded bridge scope, and no semantic split from the PWA.

Questions

• Which native affordance changes your daily writing experience most?
• Where should desktop multi-window behavior differ from the PWA, and where must it remain identical?
• Which notifications, tray actions, or updater flows are genuinely useful?
• What large-project or low-end behavior should be a release gate?
• Which PWA strengths should remain intentionally better?
• What would make Qt Quick/QML feel native without creating a second product authority?

Relationship to implementation

This Discussion is future product and UX exploration. #332 and the binding native roadmap remain authoritative for architecture, gates, implementation, and sequencing. This Discussion does not modify the roadmap, start Qt work, or change acceptance criteria.