UI

UI strategy in EngineeringOS should be treated as a long-term architectural decision, not just as a toolkit choice. The platform should move away from coupling itself to legacy widget-era assumptions, but it should also avoid making any single modern UI framework the permanent center of the system. The right long-term direction is to replace framework dependence with a stable semantic UI boundary.

Core Principle

The UI should be replaceable. EngineeringOS should not bind its semantic and compiler architecture to Qt, Compose, Slint, GPUI, React, or any other single presentation stack. The compiler should produce stable semantic structures, and UI frameworks should consume those structures through an adapter layer.

Engineering Language
        ->
Engineering IR
        ->
Compiler
        ->
UI Adapter
        ->
Slint / GPUI / Compose / Web

This follows the same architectural rule used elsewhere in EngineeringOS: own the abstraction, not the renderer.

This UI boundary should be understood as downstream of a deeper architectural separation described in Layout And Geometry. EngineeringOS should distinguish between Engineering IR, Layout IR, and Geometry IR. UI frameworks consume those contracts; they do not define them.

Why Qt Is Not The Long-Term Center

Qt remains a strong desktop framework, especially for traditional engineering applications. It has deep cross-platform support, a large ecosystem, and long industrial history. But it was shaped around desktop widgets, mouse-driven interaction, imperative UI logic, and product assumptions from an earlier software era.

That makes Qt a poor long-term center for EngineeringOS. The platform is aiming for semantic editing, AI-assisted workflows, collaborative evolution, browser delivery, and renderer replaceability. In that context, Qt can remain a compatibility reference or transitional UI option, but it should not define the architecture of a new platform.

Comparative View

The point of this comparison is not to declare one universal winner. It is to show that the UI framework should remain an implementation choice below a stable semantic boundary.

Framework Assessment

Slint is attractive because it is lightweight, declarative, modern, and Rust-centered. It looks much cleaner than Qt for future-oriented engineering software, especially where rendering discipline and modularity matter. Its weakness is ecosystem scale and relative youth.

GPUI is interesting because it is GPU-first, async-oriented, and modern in its rendering philosophy. But it is still early, lacks industrial ecosystem depth, and does not yet offer a convincing browser or mobile story. It is promising, but not a safe sole bet for the platform.

Compose Multiplatform remains the strongest default choice for EngineeringOS today. It aligns with the broader Kotlin direction of the platform, supports desktop and browser delivery through WASM, and gives a practical route to mobile if that becomes relevant. Most importantly, it fits the current stack without forcing the project to split its product surface too early.

Recommended Direction

The recommended approach is not to choose one UI forever. It is to define a UI abstraction and let multiple renderers exist behind it.

Compiler
      ->
ViewModel
      ->
UI API
      ->
Compose
Slint
GPUI
React
Web

The compiler should never need to know which UI exists. That separation makes it possible to evolve the presentation layer without destabilizing the semantic core.

Semantic View Model

EngineeringOS should eventually define its own Semantic View Model, just as it defines Engineering IR for engineering meaning. Instead of letting a UI framework talk directly to compiler internals, the platform should expose a stable view-oriented semantic contract.

Engineering IR
        ->
Semantic View Model
        ->
UI Renderer
        ->
Compose / Slint / GPUI / React

This would make UI framework replacement an implementation detail rather than a platform crisis. It would also keep Studio aligned with the central rule of EngineeringOS: the stable asset is the model and its contracts, not the renderer.

Where Rust Fits

Rust is useful in the UI story, but not as the default language for the whole application. Its strongest role is in rendering, geometry-adjacent performance work, GPU paths, and high-performance algorithms. Kotlin remains the better home for compiler logic, DSLs, ontology, AI orchestration, plugin contracts, and business logic.

Rust
-----
Renderer
Geometry
GPU
High-performance algorithms

Kotlin
------
Compiler
DSL
Ontology
AI
Plugin system
Business logic

Proto/gRPC
----------
Communication

This split lets each language serve its strengths without forcing one implementation stack to absorb every concern.

Recommended Stack Today

If EngineeringOS were started today, the most pragmatic default would be:

• Core platform: Kotlin Multiplatform
• Compiler: Kotlin
• DSL: Kotlin
• Ontology: Kotlin
• AI orchestration: Kotlin
• Geometry: OCCT
• Rendering engine: Rust where performance justifies it
• Primary UI: Compose Multiplatform
• Web delivery: Compose WASM
• Experimental secondary UI path: Slint

That combination keeps the platform modular while avoiding dependence on a single UI technology. It also keeps the central architectural promise intact: the semantic layer remains the durable contract, and the UI remains replaceable.