If someone is well (enough) versed in putting together an AI, then I'm hoping
that Moray can be resurrected upon completion of this crucial step.

AI analysis:



- truly cross‑platform (Windows/macOS/Linux),
- performant with 3D viewports (OpenGL/Vulkan/Metal via abstraction),

theming, HiDPI),
- easy to ship and maintain (installers, updates, crash reporting),


Below is a short **top‑tier shortlist**, then a deeper rundown with
pros/cons and selection criteria.

---

## The shortlist (recommended options)


- **Why**: Best all‑around for a pro DCC app: docking, complex widgets,
menus/shortcuts, internationalization, accessibility, HiDPI,
multi‑monitor, and first‑class OpenGL/Vulkan integration. Mature,
well‑documented, and widely used in CAD/DCC tools.
- **Rendering**: QOpenGLWidget/QOpenGLWindow or custom Vulkan via QRhi (Qt 6).
Stable input handling for 3D navigation.
- **Scripting**: Qt for Python (PySide6) is excellent for extending tools.
- **Drawbacks**: Licensing cost (commercial) or LGPL compliance; QML learning
curve if you go that route; large framework.

**Best fit if** Moray is C++ and you want a native, professional UX with minimal
surprises.

---


- **Why**: Classic C++ with native controls and permissive licensing. Simpler
mental model than Qt; easy to embed an OpenGL canvas. Produces

- **Trade‑offs**: Smaller ecosystem than Qt; fewer high‑level

plumbing work for very polished UX.




---


- **Why**: Lightning fast to develop, great for custom viewports, debug panes,
live inspectors, docking/undocking (docking branch). Cross‑platform via
backend bindings (GL/Vulkan/Metal).

localization need work; printing and native file pickers are not



engines) and control everything about the 3D workflow. Fantastic for a modeler
used by power users.

---


- **Why**: MVVM, XAML‑like, runs on Windows/macOS/Linux. Docker‑like
docking ecosystems, custom control authoring, and decent OpenGL/Vulkan interop
via GLControl/Skia.
- **Trade‑offs**: Less battle‑tested for heavy CAD/DCC than Qt;

macOS/Linux.

**Best fit if** your team prefers C#/.NET and wants a cohesive desktop framework
without going to Electron.

---


- **Why**: Fast rendering via Skia, good theming, fast iteration, decent desktop
story now. Embedding native 3D via platform channels or texture widgets is
doable.
- **Trade‑offs**: Complex or performance‑critical 3D embedding is
more involved; fewer desktop‑specific affordances than Qt; accessibility


**Best fit if** you want a custom‑drawn, uniform look and have strong
Flutter skills, and the 3D viewport is a native child you integrate.

---


- **Why**: Much lighter than Electron; lets you build the UI in web tech while
your 3D core is native (Rust/C++), displayed in a GL/Vulkan window or via
canvas/WebGPU in a webview.
- **Trade‑offs**: Web UI for a pro desktop tool can be tricky
(menus/shortcuts/docking need libraries); 3D in WebView (WebGL/WebGPU) may lag
native performance/driver support.

**Best fit if** your team is strong in web UI and you want tiny installers vs
Electron, while keeping a native viewport window.

---


- **Why**: Massive ecosystem, great developer velocity. Plenty of
docking/shortcut/state libraries. Easy auto‑update and tooling.
- **Trade‑offs**: Large footprint; integrating a high‑perf native
viewport either means a native node module (maintenance) or running


**Best fit if** your team is web‑heavy and shipping speed + UI flexibility
beat native feel and footprint concerns.

---

## Also‑ran / niche options (consider if they match your constraints)

- **GTK (C)**: Native on Linux; macOS/Windows support exists but not ideal for

- **JUCE (C++)**: Terrific for audio apps; usable for general UI, but less
ergonomic for CAD/DCC docking/workspaces.
- **Kivy (Python)**: Good for Python apps and touch‑UIs; not typical for
pro DCC desktop.

Rust‑first, but fewer desktop affordances than Qt.

---

## What matters for a modeler like Moray (checklist)

1. **3D viewport integration**

excellent).
   - Input correctness: raw mouse events, high‑polling devices,
3‑button mice, tablet/stylus.
   - Multi‑viewport, split views, synchronized cameras.

2. **Pro desktop ergonomics**
   - Docking/undocking, detachable panels, floating tool windows.
   - Customizable keybindings, context menus, command palette.
   - Persistent layouts/workspaces; multiple monitors; HiDPI scaling.

3. **Performance & stability**
   - Main‑thread vs render‑thread separation.
   - V‑sync control, frame pacing, minimal input latency.
   - Robust crash handling (minidumps), logging, telemetry, safe autosave.

4. **Extensibility**
   - Scripting (Python is popular in DCC): expose commands, operators, and UI
panels.
   - Plugin ABI: versioning, sandboxing, plugin UIs embedded in the main dock
system.

5. **Build & ship**
   - Cross‑platform CI, code signing, notarization (macOS),
MSIX/DMG/AppImage.
   - Updaters (Sparkle/Squirrel/WinSparkle) or built‑in (Electron).

6. **UX quality & compliance**
   - Accessibility (screen readers, focus order, contrast).
   - Localization (LTR/RTL), Unicode text.
   - Input methods (IME), file dialogs, color management.

---

## Suggested architectural patterns

- **Core engine in C++** (geometry ops, scene graph, serializers, POV-Ray
export).
- **UI shell via**:
  - **Qt Widgets** (classic) or **Qt Quick (QML)** for richer,
GPU‑accelerated UI.
  - Or **Dear ImGui** if you want a tool‑centric look with blazing dev
speed.
- **Rendering**: Separate render thread with shared context; embed into UI via

- **Command system**: Central command bus with undo/redo stack; expose to
scripting (Python) and keybindings.
- **Data model**: Scene graph + component system; change notifications
(signals/slots in Qt) to update panels efficiently.
- **Plugin API**: Stable C ABI or C++ with pimpl; UI plugin slots for
panels/tools.

---

## Practical recommendations by scenario


for traditional tool UI + QOpenGLWidget; or QML if you want modern animations
and GPU‑accelerated UI chrome. Add PySide6 for scripting.
- **You want rapid iteration and control over every pixel** → **Dear ImGui
(docking)** + your own render backend. Pair with a small platform library
(GLFW/SDL). Build native file dialogs via tiny bridge libs.

(OpenTK/Skia/Vulkan) and the rest in XAML/MVVM.

**Electron** second (ecosystem). Keep the 3D viewport native where possible.

---

## A small decision matrix

| Criterion | Qt | wxWidgets | Dear ImGui | Avalonia | Flutter | Tauri |
Electron |
|---|---|---:|---:|---:|---:|---:|---:|
| Native desktop polish | **★★★★★** |
★★★★☆ | ★★☆☆☆ |
★★★★☆ | ★★★★☆ |
★★★☆☆ | ★★★★☆ |
| 3D viewport embedding | **★★★★★** |
★★★★☆ | **★★★★★** |
★★★★☆ | ★★★☆☆ |
★★★☆☆ | ★★★☆☆ |
| Docking & complex panels | **★★★★★** |
★★★★☆ | ★★★★☆
(docking branch) | ★★★★☆ |
★★★☆☆ | ★★★☆☆ |
★★★★☆ |
| Accessibility/i18n | **★★★★★** |
★★★★☆ | ★★☆☆☆ |
★★★★☆ | ★★★★☆ |
★★★☆☆ | ★★★★☆ |
| Dev velocity | ★★★★☆ |
★★★☆☆ | **★★★★★** |
★★★★☆ | ★★★★☆ |
★★★★☆ | **★★★★★** |
| Footprint | ★★★☆☆ |
★★★★☆ | **★★★★★** |
★★★★☆ | ★★★★☆ |
**★★★★★** | ★★☆☆☆ |
| License/business | Comm/LGPL | **Permissive/LGPL** | MIT | OSS (MIT) |
BSD‑style | MIT | MIT |

(Stars are relative to this use case.)

---

## Next steps I can help with

1. **Pick the stack based on your constraints**:
   - Primary language (C++/C#/Rust/JS)?
   - OS targets (Windows/macOS/Linux) and minimum versions?
   - Licensing constraints (LGPL acceptable? commercial ok?)
   - Need native look vs custom look?
   - Must‑have features (e.g., detachable docks, tablet support,
multi‑viewport)?
2. **Architecture sketch** for your chosen stack (module boundaries, threading,
plugin ABI).

properties panel, command system with undo/redo, layout persistence, and file
open/save.

---

### Quick recommendation (if I had to choose one)
If Moray remains C++ and targets all three desktop OSes with a polished,
professional UX, **Qt 6** is the most robust and future‑proof choice. If
you want maximum developer speed and are comfortable with a non‑native UI,

power‑user modeler.

---

Post a reply to this message