Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Leonxlnx/todobar/llms.txt

Use this file to discover all available pages before exploring further.

Todobar is organized into three main layers: a React UI that knows nothing about how it is hosted, a task domain model that owns the data, and a runtime adapter that bridges the UI to either a browser preview or the Tauri native shell. This separation keeps the interface portable while native desktop capabilities remain explicit, permissioned, and replaceable.

​
Runtime layers

React UI
  -> task domain model
  -> runtime adapter
    -> web preview
    -> Tauri desktop shell
    -> optional Electron shell
The UI asks the runtime adapter for capabilities — open or close the sidebar, register a global shortcut, position the window on the active monitor, read and write local storage, request integration permissions, or invoke MCP and AI actions. The adapter hides whether the host is a browser or a native process.

​
Native shell

The current desktop build targets Tauri v2. It uses the operating system WebView so the binary stays small, and it pulls in Tauri plugins for the capabilities that browsers cannot provide. The main window is configured in tauri.conf.json as frameless, always-on-top, transparent, and skipped from the taskbar: 
{
  "label": "main",
  "title": "Todobar",
  "width": 442,
  "height": 84,
  "resizable": false,
  "decorations": false,
  "alwaysOnTop": true,
  "skipTaskbar": true,
  "focus": false,
  "transparent": true,
  "shadow": false
}
The Rust backend positions the window per the chosen dock edge and clamps the panel width so it fits on narrow monitors. Transparent regions outside the handle and open panel pass pointer events through to the application behind Todobar — this is the click-through behavior that lets Todobar stay visible without blocking your other apps.

​
Tauri plugins

PluginPurpose
@tauri-apps/plugin-global-shortcutAlt + T / Alt + Shift + T global toggle
@tauri-apps/plugin-autostartLaunch Todobar at system login
tauri-plugin-single-instancePrevent duplicate sidebar windows
Tray and menu-bar control uses the built-in Tauri tray APIs. Two tray events drive sidebar behavior: todobar-tray-toggle opens and closes the panel, and todobar-tray-settings opens the settings view.

​
Data model

​
Task

The core unit of work is defined in src/tasks.ts: 
export type Task = {
  id: number
  title: string
  meta: string
  priority: 'focus' | 'normal' | 'later'
  reminderAt?: string
  done?: boolean
}
priority drives visual treatment: focus tasks appear highlighted, later tasks are visually de-emphasized. reminderAt stores an ISO timestamp for the built-in reminder system.

​
SidebarSettings

All user-configurable appearance and behavior options are captured in the SidebarSettings type defined in src/sidebarSettings.ts: 
export type SidebarSettings = {
  dockEdge: 'right' | 'left' | 'top' | 'bottom'
  panelWidth: number        // clamped 320–560 px
  tabWidth: number          // clamped 26–88 px
  handleHeight: number      // clamped 56–176 px
  handleY: number           // screen-edge position 0–100 %
  motionMs: number          // animation duration, clamped 140–360 ms
  panelRadius: number       // clamped 12–28 px
  surfaceAlpha: number      // clamped 86–100
  taskRowHeight: number     // clamped 40–62 px
  taskGap: number           // clamped 4–14 px
  taskTextSize: number      // clamped 11–14 px
  showCompleted: boolean
  launchAtLogin: boolean
  notificationsEnabled: boolean
  theme: 'light' | 'dark'
  visualStyle: ThemePreset
  sectionOrder: SectionId[] // ['today', 'calendar', 'lists']
}
Settings are persisted to browser localStorage under a versioned key and sanitized on every read to handle missing or legacy fields.

​
Storage

The current prototype stores tasks and settings in browser localStorage inside the Tauri WebView. This provides immediate persistence without a native database dependency. SQLite (or an equivalent embedded store) is planned for a future version. When that migration happens, the runtime adapter pattern means the UI does not need to change — only the adapter implementation.

​
Future layers

​
AI planning

AI is planned as an optional planning layer, not as a database or silent background process. It can propose task edits, summaries, and next actions. The user must approve any writes that originate from external context. The approval flow and an audit log will be visible in the UI.

​
MCP adapters

External context will enter Todobar through MCP adapters with a defined interface: 
listTools()
requestPermission(scope)
readContext(query)
proposeTasks(context)
applyApprovedChanges(changes)
This shape isolates GitHub, calendar, notes, filesystem, and future services from the task UI, so adding a new connector cannot accidentally introduce silent reads or writes.

​
Permission model

Todobar treats every external connection as sensitive:
  • No silent sync
  • No hidden AI reads
  • No automatic third-party writes
  • Visible data scopes per connection
  • Clear audit trail for imported or AI-created tasks
The current prototype has no network access at all. All data lives on your machine in the app WebView’s local storage.

Build docs developers (and LLMs) love

Get started for freeTalk to us