Qleany

Define your entities in YAML. Get a complete, tested architecture in C++20/Qt6 or Rust: controllers, repositories, undo/redo, reactive models, and ready-to-compile UIs.

No framework. No runtime. No Qleany dependencies in your code.

The generated code is yours: plain C++ classes and Rust structs using standard libraries (Qt, QCoro). Modify it, extend it, delete Qleany afterward. You're not adopting a framework that will haunt your codebase for years or burn you when the maintainer moves on: because the generated code carries no Qleany dependency at all.

Try it now

Run: pipx install qleany && qleany demo

And follow the instructions.

Deps: clang-format for C++/Qt, or cargo-fmt for Rust. If you are missing a dependency, it will tell you.

Or type qleany to launch the GUI and click on the green "Run demo" button.

Intro

Qt provides excellent widgets and signals, but little guidance on organizing a 30,000-line application. Rust's GUI ecosystem is growing fast, but there's nothing to help you structure what sits behind the UI. Qleany fills that gap. Write a YAML manifest describing your entities, relationships, and features. Qleany generates the rest: the database layer, the repository infrastructure, the event system, the controller wiring, and — if you need it — a multi-stack undo/redo system with cascade snapshot/restore for entity trees. For C++/Qt, it also generates reactive QML models that update themselves, and JavaScript mock controllers so your UI developer can work without waiting for the backend.

Once the code is generated, your work is two things: fill in the use case bodies where the TODOs are, and build your UI. The rest is done. Think of it as getting the framework without adopting one.

Qleany is not a scaffolding tool, it's an architecture materializer.

For a 17-entity project, that's roughly 410 files in C++/Qt or 175 in Rust, all compiling, all internally consistent, with a generated test suite that validates the infrastructure before you write a single line of business logic. The generated code is deliberately straightforward, readable and modifiable by a developer with a few years of experience, not a showcase of advanced language features.

Qleany follows Package by Feature (Vertical Slice Architecture) principles. Define your entities and features once, generate consistent architecture across Rust and C++/Qt with baked-in (empty) UIs. Qleany's own Slint-based tool is built using the same patterns it generates.

Key Features

• Complete CRUD infrastructure: Controllers, DTOs, use cases, repositories per entity
• Undo/redo system (optional): Command-based with multi-stack scoping, composite grouping, and failure strategies; async execution with QCoro coroutines in C++/Qt, synchronous in Rust; cascade snapshot/restore for entity trees
• GUI skeleton generation: Ready-to-compile frontend code for QtQuick, QtWidgets, Slint, or CLI
• Mobile bridge: UniFFI-based iOS (Swift) and Android (Kotlin) support with generated async wrappers, event callbacks, and platform READMEs
• Models: C++/Qt only: auto-updating list models and single-entity wrappers with event-driven refresh
• Reactive QML models: Auto-updating list models and single-entity wrappers with event-driven refresh (C++/Qt)
• QML mocks: JavaScript stubs that simulate async behavior, enabling UI development without a backend (C++/Qt)
• Relationship management: Uniform junction tables with ordering, two-layer caching, bidirectional navigation, and cascade deletion
• Event system: Thread-safe, decoupled communication between features
• Event Buffer: Send events only if the command succeeds
• Generated test suite: Junction table operations, undo/redo behavior, and async integration tests

Documentation

| Document | Purpose | |--------------------------------------------------------------------|--------------------------------------------------------------------------------| | Quick Start - Rust | Step-by-step tutorial building a complete application | | Quick Start - C++/Qt | Step-by-step tutorial building a complete application | | Manifest Reference | Entity options, field types, relationships, features and use cases | | Design Philosophy | Clean Architecture background, package by feature, Rust module structure | | How Operations Flow | How data flows through the application, events | | Regeneration Workflow | How file generation works, what gets overwritten, files that must stay in sync | | Undo-Redo Architecture | Entity tree structure, undoable vs non-undoable, configuration patterns | | Migration Guide | Manifest changes and migration strategies | | QML Integration | Reactive models, mocks, and event system for C++/Qt | | Generated Infrastructure - C++/Qt | Database layer, repositories, and file organization details | | Generated Infrastructure - Rust | Database layer, repositories, and file organization details | | API Reference - C++/Qt | Entity controller, feature controller, and custom UoW macros | | API Reference - Rust | Entity controller, feature controller, and custom UoW proc macros | | Mobile Bridge Development | UniFFI bridge for iOS (Swift) and Android (Kotlin) | | Troubleshooting | Common issues and how to fix them |

New to Qleany? Start with the Quick Start Guide - C++/Qt or Quick Start Guide - Rust. Then return here for reference.

---

Is Qleany the Right Fit?

When Qleany Makes Sense

Data-centric applications that will grow in complexity over time. Think document editors, project management tools, creative applications, or anything where users manipulate structured data and expect undo/redo to work reliably. This applies equally to desktop and mobile: a note-taking app on Plasma Mobile has the same architectural needs as one on desktop Linux.

Complex CLI tools in Rust: tools like git that manage structured data, have multiple subcommands, and need consistent internal architecture. Qleany itself is built this way: type qleany -h to see a CLI interface backed by the same architecture that powers its Slint GUI.

Applications targeting multiple platforms: if you're building for desktop Linux and want to support Plasma Mobile or Ubuntu Touch with the same codebase, Qleany's generated backend works identically across all of them. Write your business logic once, swap UI frontends as needed.

Mobile apps with a Rust backend: if you are targeting iOS (Swift) or Android (Kotlin), enable rust_ios and/or rust_android in your manifest. Qleany generates a complete UniFFI bridge with platform-native async wrappers. See the Mobile Bridge Development guide. This solution is doubly interesting if you want to share the backend between desktop and mobile.

Applications needing multiple Qt frontends: if you need QtQuick, QtWidgets (or any combination of them simultaneously), Qleany generates a ready-to-compile backend architecture that any of these frontends can consume. The generated controllers, repositories, and event system work identically regardless of which UI toolkit you choose.

Solo developers or small teams without established architectural patterns. Qt provides excellent widgets and signals, but little guidance on organizing a 30,000-line application (or I couldn't find it). Qleany gives you that structure immediately, with patterns validated through real-world use in Skribisto.

Projects that will grow incrementally: the manifest-driven approach means you can define a new entity, regenerate the architecture, and immediately have a working controller, repository, DTOs, and use cases. The consistency this brings across your codebase is hard to achieve manually.

When to Reconsider

For simple utilities or single-purpose tools, Qleany introduces more infrastructure than you need. If your application doesn't have complex entity relationships, doesn't need undo/redo, and won't grow significantly, a hand-written architecture may serve you better. Yet since you only have to fill a few blank spots, using Qleany can save you time.

If you're working with a team that already has established patterns, introducing Qleany means everyone needs to learn its conventions. The generated code is readable and follows clear patterns, but it represents a specific way of doing things. Discuss with your team before adopting it. Do