|
 |
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
|
|
|
|
hi,
Thorsten <tho### [at] trf de> wrote:
> On 04.11.2025 17:56, jr wrote:
> > ... making the code available on platforms other than MS
> > Windows would require the UI "disentangled" though; fwiw, imo, for someone with
> > the right "skill set" it would not be a "onerous" job. and having Moray on an X
> > desktop would be nice.
>
> Well, it is so old, it should run fine in Wine ;-)
perhaps it does. that would not address "the issue(s)" though. for one, MS
s/ware would still be "the" prerequisite. also, as you pointed out, the code
could do with the work needed to make it fit for modern C++ compilers/libraries,
so why put up with some 32-bit so-last-century program, when we have the source
in hand ?
regards, jr.
Post a reply to this message
|
|
