Skip to content
Timbra
Development status
Timetabling · Desktop · In development

A timetable that can
explain itself

Timbra plans lessons at schools, vocational schools and universities. The solver does the maths; the interface gives a reason for every rejection right where it happens. The app is still in development.

Four perspectives, one grid

Class, teacher, room and the overall plan share the same grid component. One status vocabulary works the same way everywhere.

Why not?

Clicking a slot shows the reason: what the situation is, which rule applies, and what would resolve it.

Usable without a mouse

Moving works from the keyboard too – pick a lesson, V, arrow keys, Enter. The same live evaluation as dragging.

01 — Overview

Plan, understand, change.

Timbra is a desktop application for timetabling. It is not a form editor for constraints: input is phrased in the language of planning (“when may this teacher teach?”), and every figure in the interface can be unfolded down to its cause. The computation is done by schedulr, the scheduling library behind Timbra. Timbra is its first complete application.

schedulr documentation →
  1. 01Explainable — every rejection names the rule and a possible way out
  2. 02Editable — moving, pinning and repairing are core workflows, not exceptions
  3. 03Versioned — save, rename, compare and publish plan versions
  4. 04Local — a desktop app with an SQLite database, no server required
02 — Features

The areas of the application.

Plan

The weekly grid with a switch between class, teacher, room and the overall plan. Lessons can be moved and pinned; three density levels drop card content in a fixed order.

Readiness

A separate step before the solver runs: missing classes, teachers or rooms, lessons without a fitting time window, subjects without a qualified teacher. Each check is complete, a gap, or blocking.

Pressure

Utilisation per room and per teacher as a percentage, plus an estimate of how solvable the plan is – visible before the solver runs for the first time.

Solver

The run in four phases: validate the input model, build a hard-valid starting solution, optimise soft constraints, save the version. The best score is recorded along the way.

Versions

Save, rename and publish plan versions. Two versions can be compared; changes are checked against the version currently on screen.

Master data and setup

Teachers with availability and teaching-load limits, rooms with features, classes, subjects, courses and lessons. Plus the time grid, planning goals, backup and a sample project to try things out.

03 — Workflow

From master data to a published version.

  1. 1Enter

    Master data and time grid

    Create classes, teachers, rooms, subjects and courses. The weekly grid is configurable, not hard-wired.

  2. 2Check

    Readiness and pressure

    Before the first run, Timbra shows gaps in the data and the utilisation of the scarce resources.

  3. 3Solve

    Run the solver

    Hard rules must hold, soft goals are optimised. The result is stored as a plan version in the database.

  4. 4Adjust

    Move and compare

    Target slots are pre-evaluated before a lesson is moved. Two versions can then be compared.

04 — Structure

Rust below, Svelte above, Tauri in between.

  1. Interface

    Svelte 5

    The views never talk to the operating system directly; they go through a client layer of their own.

    Svelte 5TypeScript
  2. Host

    Tauri 2

    Tauri is the desktop host: windows, notifications, permissions. The domain logic knows nothing about it.

    Tauri 2Rust
  3. Platform

    Origin

    The in-house platform layer for Rust/Tauri apps: error model, storage, events, background jobs, permission profiles.

    SQLiteLeast privilege
  4. Scheduling

    schedulr

    The scheduling library does the computation. Timbra maps qualification, availability, pinned lessons and course patterns onto it.

    RustConstraints
05 — Principles

Two decisions that shape everything else.

Explanation is mandatory

No separate report: the reason appears in the same view where the rejection arises. Scores are structures you can unfold, not bare numbers.

Colour never carries alone

Every state has a colour, a symbol and a text. Pinned lessons get a text badge instead of an icon – a padlock at 11 px is unreadable in a dense grid.

Keyboard before drag and drop

Pre-evaluated target slots are the foundation; dragging is added on top. Every cell carries a name such as “Tuesday, period 3, free”.

Testable without a desktop

The domain logic runs in tests without a Tauri session. The scheduling module currently holds more than 100 Rust tests.

Development status — as of September 2026

Built

Scheduling core

Persisted master data, a configurable time grid, readiness checks, the utilisation view, the solver bound to schedulr, plan versions with comparison, backup and a sample project.

In progress

Sharpening rules and conflicts

Recently added: course patterns as a hard rule, double booking as a hard conflict, and a check against stale solutions. The interface is being built out along those rules.

Planned

A first released version

Signed installers, import from existing timetabling systems and output of finished plans. No date is promised for this.

Target platforms
  • macOS
  • Windows
  • Linux
Rust · Tauri 2 · Svelte 5 · SQLite · schedulr
06 — Limits

What Timbra is not today.

Timbra is being built, not sold. This section says what that means in practice.

Not publicly available

There is no download, no trial version and no public source code. No release date is promised either.

No installers

The app is built from source. Signed packages and an update mechanism are prepared but switched off.

No school year planned yet

Timbra runs on sample and test data. Use at a school across a full school year is still ahead.

No interfaces

Import from existing timetabling software and export into cover or administration systems do not exist yet.

07 — FAQ

Frequently asked questions.

Can I try Timbra yet?

No. Timbra is in development, the repository is not public and there is no version to download. As of September 2026.

What is the difference between Timbra and schedulr?

schedulr is the scheduling library in Rust: activities, resources, time windows, rules and the scoring of a solution. Timbra is the desktop application on top of it that models the timetabling case – classes, teachers, rooms, subjects – and makes the result workable.

Where is the data stored?

In a local SQLite database on the machine running the app. Planning needs neither an account nor a server.

What does the solver do with a plan that does not work out?

Hard rules such as double bookings must not be violated; soft goals are weighed against each other and reported as a score. Before the run, the readiness view shows which checks are blocking, and the pressure view shows which rooms and teachers are scarce.

Can it be operated without a mouse?

That is the basis of the interaction, not an addition: target slots are pre-evaluated so they can be reached without a pointing device. Status symbols and cell labels are mandatory, because colour alone must not carry a statement.

Which institutions is Timbra meant for?

Schools, vocational schools and universities – plans with classes or courses, teachers, rooms and recurring patterns across a week.

What will Timbra cost?

There is no answer to that yet. Price and licence model will be set only with a release.

A plan that justifies what it does.

Timbra is in development. There is nothing to download yet – we are happy to answer questions about the project.