Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA
github.com
GitHub - Unique-Digital-Resources/AppShell: app shell with ready to use app engine
app shell with ready to use app engine
Warning:
It is still in the early stages of development.
# AppShell — A Headless Application Foundation for Rust
**What if developers could reuse an application's core infrastructure instead of rebuilding it for every project?**
[AppShell](https://github.com/Unique-Digital-Resources/AppShell) is an early-stage, open-source Rust project exploring this idea. It combines two complementary layers in one library:
- **App Engine:** Generic application runtime infrastructure for managing execution, state, lifecycle, communication, history, resources, services, plugins, and configuration.
- **Domain Foundation:** Reusable, headless models for organizing and editing data through 2D canvases, timelines, layer hierarchies, node graphs, 3D spatial structures, tables, and text editing.
The goal is to provide reusable building blocks between an application's interface and its actual domain logic, without forcing every application to adopt the same UI framework, domain model, or architecture.
## Core features
**1. Application runtime infrastructure**
- Explicit lifecycle management and cleanup.
- Commands, managed tasks, scheduling, cancellation, deadlines, and progress reporting.
- Events and signals for decoupled communication.
- Undo/redo, operation history, replay, and transactions.
- Resource management with automatic release and dependency tracking.
- Services, extensibility through plugins, and permission-related mechanisms.
- Configuration, preferences, persistence abstractions, serialization, and concurrency support.
**2. Reusable domain-editing models**
- Canvas2D for spatial organization.
- Timeline for tracks, clips, and keyframes.
- Layers for hierarchical organization.
- NodeGraph for nodes, ports, and connections.
- Viewport3D for spatial relationships and transforms.
- Table for structured tabular data.
- TextEditor for text operations and Unicode-aware positions.
These are **headless models**, not finished editors. They represent and manipulate data; the application decides how to render and interact with it.
**3. A relation system**
Developers can define relationships between properties and supply the logic that determines how changes propagate. This supports direct or cascading propagation, priorities, batching, and cycle protection.
**4. A deliberately layered architecture**
The intended dependency direction is:
`Application/UI/API → Domain Engine → Domain Foundation → App Engine`
The App Engine handles generic mechanisms. The Domain Foundation supplies reusable organizational models. The application's Domain Engine defines what its objects mean and what its operations actually do. UI, API, CLI, and MCP integrations remain separate concerns.
**5. Minimal default dependencies**
AppShell aims to work with zero external crates by default, with optional integrations such as Tokio for asynchronous execution and Serde for serialization.
## What makes it interesting?
The most interesting aspect is not simply having a command system, an event bus, or a plugin mechanism. Those already exist in various libraries.
It is the attempt to combine **runtime infrastructure, reusable editing models, property relationships, and undoable operations** in a single headless foundation, while preserving separation between application meaning, execution infrastructure, and presentation.
That could be especially useful for creative applications, visual editors, CAD-like tools, node-based systems, document applications, and other software where structured data changes through many connected operations.
## What AppShell is not
- Not a UI framework or widget toolkit.
- Not a complete application or ready-made visual editor.
- Not a game engine or rendering engine.
- Not a database or networking framework.
- Not an API server or MCP implementation.
- Not an AI agent framework.
- Not a replacement for application-specific business logic.
Instead, it is designed to provide infrastructure that applications can build on, including applications that may later expose their capabilities through APIs or AI-agent integrations.
## The long-term idea
The broader architectural ambition is to make application development more composable: reuse common runtime mechanisms, reuse domain structures where they genuinely fit, and keep application-specific meaning separate.
Rather than prescribing how an application must look or what it must do, AppShell aims to provide a foundation on which different applications can establish their own behavior and interfaces.
**Project status:** Early-stage development. The architecture and feature set are documented, but production readiness, long-term stability, performance, and real-world integration still need to be established through implementation, testing, and practical use.
Repository: https://github.com/Unique-Digital-Resources/AppShell
Documentation: https://unique-digital-resources.github.io/AppShell-Documentation/
Why?:
I have long wanted to create desktop applications,or even better , cross-platform applications for digital design, IDEs, engineering CAD software..etc.
The task is inherently far from simple; even with the advent of the AI revolution, reaching an initial minimal release for just a single application remains a complex undertaking..something I have actually attempted several times without success.
So, I decided to create a shared foundational base that I could reuse to build future application projects upon, and that took me about three weeks.
Although I made extensive use of AI in this project, I first conducted in-depth research into various architectures to arrive at the current one.
In this context, we have all witnessed the emergence of "AppCraft"—a collection of open-source alternative applications to Adobe software. Although I aim to create applications in the same domains and for similar purposes, this project takes a different approach: rather than delivering specific applications, the goal is to provide a shared foundation upon which applications can be built.
Ultimately, this repository serves as a starting point to gauge the community's interest in the idea.
Although I have created tests for this project, I am still unsure of its readiness or their suitability...so I wanted someone to take a look at it to preview it.
3 posts - 2 participants
Read full topic
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | [Project] sol: A self-contained browser kernel written in Rust | 0 | 9.76 | 18-10-2026 |
| 2 | Zaxis 0.0.5: immediate-mode GUI on wgpu, embeddable in a host's wgpu pass, with an real overlay layer for other processes | 0 | 10.2 | 11-10-2026 |
| 3 | FUI-RS: retained Rust UI for WebAssembly and native desktop without a WebView | 0 | 11.54 | 30-07-2026 |
| 4 | I wrote a small library for exclusive component filtering in bevy | 0 | 14.93 | 13-10-2026 |
| 5 | CircuitCraft: a Rust desktop circuit editor with ngspice simulation | 0 | 6.46 | 18-10-2026 |
| 6 | Hotcode: easy to use hot-reload | 0 | 9.84 | 09-10-2026 |
| 7 | Sping 1.5.5 — a cross-platform network diagnostics CLI written in Rust | 0 | 9.19 | 10-10-2026 |
| 8 | Looking for contributors: Rust transparent proxy & protocol parsing project | 5 | 7 | 08-07-2026 |
| 9 | Maplike - Crate with traits for abstract containers and operations on them | 2 | 7 | 06-07-2026 |
| 10 | I wrote my M.Sc. thesis on using the Rust type system in 3D graphics | 0 | 7 | 29-06-2026 |