| summary | Current ActionRail tech stack decision and what to avoid for the Maya viewport UI framework. | |||
|---|---|---|---|---|
| read_when |
|
Build ActionRail as:
Python 3.11 in Maya
+ PySide6 / Qt Widgets
+ custom Qt rail overlay anchored to model-panel geometry
+ maya.cmds / OpenMayaUI / shiboken6
+ JSON specs and Python builder API
+ Maya runtime commands for publishable hotkey targets
+ SVG icons with PNG fallbacks
+ Maya .mod packaging
+ MayaSessiond verification
- Use Maya's bundled Python and Qt. Maya 2026 is Python 3.11.4 with Qt/PySide6 6.5.3.
- Use
QApplication.instance(). Never create a newQApplication. - Parent visible rails under Maya's main Qt window, use model-panel widgets for
anchor geometry, and keep stable
objectName()values. - Use
maya.cmdsfirst. Use Maya API 2.0 only wherecmdsis not enough. - Use Maya runtime commands as the bridge for ActionRail actions and slots that should be bindable through Maya's Hotkey Editor.
- Avoid PyMEL unless explicitly requested.
- Use PySide6 / Qt Widgets for the MVP.
- Implement a custom Qt overlay host that resolves model-panel geometry and positions small frameless rail windows over the viewport.
- Use custom
QWidget/QPaintercontrols for the compact stack when standard buttons fight the design. - Use
QActionconcepts internally for reusable commands, even if widgets are custom-painted. - Use QSS/theme tokens for consistent colors, spacing, radius, and states.
- Design for Qt6 High DPI from the first prototype.
- Build flyouts and command rings in Qt first. Do not move radial/menu hit testing to Viewport 2.0 unless Qt proves insufficient.
Maya 2026 includes Autodesk's moverlay module for Qt-based 2D overlays over Maya UI.
Spike it as a reference or adapter when overlay work needs it, but do not make it the core until it proves:
- viewport/model-panel anchoring works for ActionRail
- it can avoid viewport-sized transparent hit areas while still anchoring to model panels
- controls can own precise hit areas
- reload cleanup is reliable
- styling can match the reference UI
- Use SVG as source icons.
- Use
actionrail.icons.import_svg_icon()for checked-in local SVG imports so safety validation, manifest path normalization, and metadata stay consistent. - Cache PNG fallbacks at 1x/2x/3x when needed.
- Track icon source, license, original URL, and import date in
icons/manifest.json. - Preferred icon sources: Lucide, Tabler Icons, Google Material Symbols, and Iconify as a discovery/import source.
- Do not load live CDN icons at runtime.
Use web tech for authoring and import workflows, not the core Maya runtime.
Good uses:
- Figma, Illustrator, Inkscape, or web icon browsers for design.
- Optional Node/TypeScript importer for Iconify JSON to local SVG.
- Optional local web preview that exports JSON/SVG.
Avoid in the MVP:
- React/Electron inside Maya.
- Required
QWebEngineView. - Remote web pages or online JavaScript bundles.
- CDN icons or runtime network dependencies.
QWebEngineView can be revisited later for a designer panel only after a runtime import probe confirms it is available and stable in the target Maya version.
Defer Viewport 2.0 until the Qt overlay MVP is stable.
Use it later for:
- non-clickable labels and guides
- object-bound viewport graphics
- high-frequency native drawing
Do not use it first for normal clickable buttons, menus, or designer UI. Interaction, hit testing, and layout are cheaper and safer in Qt.
- Ship as a Maya module:
ActionRail.mod,scripts/actionrail,icons,presets,examples. - Verify with
GG_MayaSessiondwhen feasible. - Add pure Python tests for specs, themes, icon manifests, and action registry code.
- Add Maya smoke tests for import/show/hide/reload once command shape stabilizes.