Onyrion/onyrion-core

Fork 0

Explore a minimal core model #1

New issue

Open

opened 2026-07-04 18:46:48 +00:00 by OniiC · 0 comments

OniiC commented

2026-07-04 18:46:48 +00:00

Owner

Context

The project preparation stage is complete.

The development environment is ready, Forgejo access is verified, the current project builds successfully, and the initial architectural direction is clear enough to begin implementation.

The next unknowns should come from implementing Onyrion itself rather than from further environment preparation.

Core direction

onyrion-core is the Wayland compositor and the mandatory foundation of the DE.

The initial internal model is:

Workspace → Layout → Tile → Group → Window

Responsibilities are conceptually separated even if they live inside the same core repository:

Wayland / wlroots mechanism
window and workspace model
layout
application/window relationships
placement and behavior policy
input
recovery primitives
IPC later, when a real shell requires it

wlroots is used for low-level compositor plumbing. Onyrion owns the actual desktop model, placement, grouping, focus, workspace behavior and UX policy.

Model assumptions

Window

Represents an application window.

Useful metadata may include:

app_id
process metadata where useful
launch origin
parent/transient relationships
user-defined rule matches

No single metadata field should be treated as the absolute identity of an application.

Group

A fundamental ordered collection of windows.

A single window may internally exist as a one-window Group while the tab UI remains hidden.

Groups are expected to support operations beyond moving one window:

split before/after a selected window
move a prefix or suffix into a new Group
merge Groups in either order
move individual windows between Groups

Tile

Owns the position of a Group in the layout.

This keeps window grouping separate from layout geometry.

Workspace

A persistent object with:

immutable internal identity
user-visible name
display order

The visible name/order must not be the internal identity.

Initial placement policy

Placement should be policy-driven.

A new normal window is placed approximately in this order:

explicit application/user rule
launch origin or meaningful parent relationship
focused Group as fallback

Transient/dialog windows should retain their relationship to the parent and should not automatically behave like ordinary tabs.

Policy should be separable from compositor mechanisms so that built-in behavior can later be changed by presets or advanced custom policy.

Recovery direction

Recovery is split by failure level:

shell crash → core remains alive, shell is respawned
repeated shell failure → minimal core-level recovery notice with terminal / recovery instructions
broken configuration/policy → emergency default configuration
core/compositor crash → external recovery through another TTY and a recovery command

The external recovery system is a later-stage feature.

Shell direction

A primitive shell should appear relatively early so that Group/tab UX and other core behavior can be tested visually.

This does not mean switching development focus from core to shell early.

The full personal migration from Hyprland to Onyrion should happen later, when:

core is close to complete for everyday use
shell is usable enough for normal work
the everyday workflow no longer depends on returning to Hyprland

First implementation focus

Explore and implement the minimum structures and invariants required for:

Window
Group
Tile
Workspace
basic Output representation
focus
normal vs transient windows
placement policy
Group ordering
Group splitting
Group merging
layout collapse when a Group disappears

Useful first model scenarios include:

first Window on an empty Workspace
additional normal Window entering the selected Group
launch-origin placement
transient/dialog handling
moving Group prefixes/suffixes
merging Groups in both orders
closing the last Window in a Group
changing Workspace display order without changing its identity

Not now

Do not design these yet unless implementation makes one of them an immediate blocker:

final shell IPC
public plugin ABI
complete configuration format
config editor
undo/application restore
desktop/files component
XWayland integration
portals
final recovery system
animations
release compatibility system

Research exit

Stop refining the abstract model when it is clear enough to connect a real Wayland xdg_toplevel to:

Window → Group → Tile → Workspace

At that point continue with the first real compositor vertical slice instead of further abstract design.

## Context The project preparation stage is complete. The development environment is ready, Forgejo access is verified, the current project builds successfully, and the initial architectural direction is clear enough to begin implementation. The next unknowns should come from implementing Onyrion itself rather than from further environment preparation. ## Core direction `onyrion-core` is the Wayland compositor and the mandatory foundation of the DE. The initial internal model is: `Workspace → Layout → Tile → Group → Window` Responsibilities are conceptually separated even if they live inside the same core repository: * Wayland / wlroots mechanism * window and workspace model * layout * application/window relationships * placement and behavior policy * input * recovery primitives * IPC later, when a real shell requires it wlroots is used for low-level compositor plumbing. Onyrion owns the actual desktop model, placement, grouping, focus, workspace behavior and UX policy. ## Model assumptions ### Window Represents an application window. Useful metadata may include: * `app_id` * process metadata where useful * launch origin * parent/transient relationships * user-defined rule matches No single metadata field should be treated as the absolute identity of an application. ### Group A fundamental ordered collection of windows. A single window may internally exist as a one-window Group while the tab UI remains hidden. Groups are expected to support operations beyond moving one window: * split before/after a selected window * move a prefix or suffix into a new Group * merge Groups in either order * move individual windows between Groups ### Tile Owns the position of a Group in the layout. This keeps window grouping separate from layout geometry. ### Workspace A persistent object with: * immutable internal identity * user-visible name * display order The visible name/order must not be the internal identity. ## Initial placement policy Placement should be policy-driven. A new normal window is placed approximately in this order: 1. explicit application/user rule 2. launch origin or meaningful parent relationship 3. focused Group as fallback Transient/dialog windows should retain their relationship to the parent and should not automatically behave like ordinary tabs. Policy should be separable from compositor mechanisms so that built-in behavior can later be changed by presets or advanced custom policy. ## Recovery direction Recovery is split by failure level: * shell crash → core remains alive, shell is respawned * repeated shell failure → minimal core-level recovery notice with terminal / recovery instructions * broken configuration/policy → emergency default configuration * core/compositor crash → external recovery through another TTY and a recovery command The external recovery system is a later-stage feature. ## Shell direction A primitive shell should appear relatively early so that Group/tab UX and other core behavior can be tested visually. This does **not** mean switching development focus from core to shell early. The full personal migration from Hyprland to Onyrion should happen later, when: * core is close to complete for everyday use * shell is usable enough for normal work * the everyday workflow no longer depends on returning to Hyprland ## First implementation focus Explore and implement the minimum structures and invariants required for: * Window * Group * Tile * Workspace * basic Output representation * focus * normal vs transient windows * placement policy * Group ordering * Group splitting * Group merging * layout collapse when a Group disappears Useful first model scenarios include: * first Window on an empty Workspace * additional normal Window entering the selected Group * launch-origin placement * transient/dialog handling * moving Group prefixes/suffixes * merging Groups in both orders * closing the last Window in a Group * changing Workspace display order without changing its identity ## Not now Do not design these yet unless implementation makes one of them an immediate blocker: * final shell IPC * public plugin ABI * complete configuration format * config editor * undo/application restore * desktop/files component * XWayland integration * portals * final recovery system * animations * release compatibility system ## Research exit Stop refining the abstract model when it is clear enough to connect a real Wayland `xdg_toplevel` to: `Window → Group → Tile → Workspace` At that point continue with the first real compositor vertical slice instead of further abstract design.

OniiC added this to the M0 — It exists milestone

2026-07-04 18:46:48 +00:00

OniiC added the

research

label

2026-07-04 18:46:48 +00:00

OniiC self-assigned this

2026-07-04 18:46:48 +00:00