Not stable yet. WolOS is in active development and the current ISO is a test build: try it in a virtual machine or on a spare disk, not on a computer you depend on.

WolOS

Pages

Manual

In development lands after WolOS 0.12

Cryswol

Write WolOS apps in one small, fast language.

What it isGet involved

What it is

Cryswol is the Crystal userland of WolOS: the language, the framework and the tooling you write apps in.

  • Language

    Crystal, compiled to a native program. Its toolchain is small and comes from the base distribution's repositories, so nothing large ships on the image.

  • Framework

    The wol shard reaches every system verb. wolkit builds views from signals. Apps never link the shell's own UI kit: they describe a view tree and the shell draws it.

  • Tooling

    wol app new makes a project that builds and passes its checks. A signed index of libraries. Rules that a test enforces.

Below the system interface nothing changes: the daemons, the shell and everything that reads untrusted input stay as they are. Cryswol is what sits above it.

Why

Apps with no default language leave an ecosystem thin. One language, native to the system, fixes that.

  • Native

    One compiled program. A short tool turns the collector off; an app tunes it, and collects when a window hides or the memory saver asks.

  • Fast

    No virtual machine to start. Heavy work runs on its own execution context so the interface never waits. A GPU surface for drawing is planned.

  • Safe

    A callback never unwinds into the system interface. A failing call raises an error that carries the system's own sentence. Touching view state from the wrong context raises in development builds.

  • Readable

    A small surface: views, signals, click blocks, spawn. One way to do each thing, and convention over configuration.

  • Every verb

    Each WolOS system verb is reachable through generated bindings, never hand-written ones. A new verb ships with its wrapper in the same change.

  • One discipline

    The standard of the rest of WolOS: docs for every public method, specs, a formatter check, and rules a test enforces.

What you can build

  • Apps

    Windows, lists, forms and notifications. A view is a function of signals; the shell draws it. In development, wol app run --watch rebuilds on save and keeps the window.

  • Plugins

    Generators, checkers and previews for plugins run as you, in the same language as the apps. Small sandboxed shell plugins keep their own light format.

  • System tools

    Command-line programs over the same bindings. The wopkg command and the Hue tool are already written in Crystal.

  • AI integrations

    The AI framework and integrations with outside services are Crystal first: designed, documented and tested there before anywhere else. GPU compute for models comes with the GPU surface.

Start any of them with wol app new <id> --template app|cli|tool|ai.

In code

Short, typed, and readable the first time.

Preview API. These are sketches from the plan, not code you can run today. Names may change before the shard ships.

A windowPreview API
require "wol"

Wol::Context.open("org.example.hello") do |ctx|
  window = ctx.window("Hello")
  window.content = ctx.stack(
    ctx.label("Hello from Cryswol."),
    ctx.button("Say it") do
      ctx.notify("Hello", "Said it.")
    end
  )
  window.show
  Wol::Loop.run(ctx)
end

The high layer over the system interface: a context, a window, a click block, a notification.

A reactive viewPreview API
require "wolkit"

count = Wolkit::Signal.new(0)
title = Wolkit.computed { "Clicked #{count.get}x" }

Wolkit.window("Counter") do
  column do
    text title
    button("Add one") { count.set(count.get + 1) }
  end
end

State is a signal. A view that reads it is drawn again when it changes, and only that part is sent.

Work off the interfacePreview API
status = Wolkit::Signal.new("Idle")

button("Check for updates") do
  status.set("Checking...")
  Wol.background do
    found = check_for_updates # your code
    status.set_later("#{found} updates")
  end
end

One rule: view state is touched on the UI context only. Blocking work goes to Wol.background and comes back through the signal.

Errors are sentencesPreview API
begin
  ctx.notify("Backup finished", "3 files copied")
rescue error : Wol::Error
  STDERR.puts "#{error.code}: #{error.message}"
end

A failed call raises Wol::Error with a code and the sentence the system wrote for a person.

A project, in a terminalPlanned
$ wol app new notes --template app
$ cd notes
$ crystal spec
$ wol app run --watch

The scaffold makes a project that builds and passes its checks. Hot reload keeps the window while the code restarts.

The standard

A language with a standard, enforced by machines, not by habit.

  • Formatter

    Every Crystal source passes the language's formatter check. The wopkg and Hue sources already do, in CI.

  • Linter

    A linter with a pinned rule set and a baseline for old debt, so new code can only get cleaner.

  • Rules catalogue

    Rules with ids, RCR-nnn, each with its reason, checked by a test that reads the sources.

  • Pinned

    The toolchain version is pinned per WolOS release. Libraries come from a signed index, by commit and source hash. Apps vendor them and never fetch at run time.

First draft of the rules

RCR-001
The collector is switched off only in the cli template.
RCR-002
No signal is written outside the UI context.
RCR-003
No hand-written lib block for a WolOS header.
RCR-004
Every public method has a doc comment.
RCR-005
No shell-out with interpolated strings: arguments only.
RCR-006
No upstream project or author names in code.

The catalogue is a draft and lands with CR5. A library enters the index with passing specs, a clean format check, docs for every public method and a compatible license.

Roadmap

Six phases, after 0.12. None gates the 0.12 release.

Today the wopkg command and the Hue tool are Crystal and ship as they are. The phases below are planned, in development after the 0.12 tag.

  1. CR1

    Bindings

    A generated low layer for every header, the wol shard and its event loop.

    Starts first planned

  2. CR2

    wolkit

    Declarative views, signals, hot reload and the one-rule concurrency check.

    After CR1 planned

  3. CR3

    GPU surface

    A drawing surface for apps that need it, a small 2D canvas on it, compute queues for AI.

    After CR1 planned

  4. CR4

    Library index

    The signed index and wol shard add, update, list, check; rebuilt at every WolOS release.

    With CR1 planned

  5. CR5

    Templates and rules

    wol app new with app, cli, tool and ai; the rules and their checker; the wolos-crystal package.

    After CR2 and CR4 planned

  6. CR6

    First apps

    A Hue GUI and a sample app, to prove the stack: both run from the menu and follow the theme.

    Last planned

Get involved

Nothing to install yet. The decision is written down, the plan is split into six streams, and the shape is still open.

Logo files: SVG · PNG 1024 · PNG 512 · PNG 64 · Single-colour SVG