reduanahmadswe/dayonedesktop

1. Overall shape

DayOne Desktop is a Windows-only Electron app with two user-facing surfaces sharing one local SQLite database: a compact “wallpaper panel” that sits on the desktop behind icons, and a full editor window for managing tasks, calendar, notes, and settings.

2. Process boundary

The architecture is split into an Electron main process under electron/ and a renderer React app under src/. The main process owns app lifecycle, windows, tray, database access, startup behavior, and native Windows integration. The renderer owns all UI and never touches the filesystem or database directly.

3. Renderer structure

The renderer is organized by feature: tasks, calendar, notes, and settings, plus shared widgets used by the wallpaper panel. src/App.tsx routes between the desktop panel and editor shell, while src/layouts/WallpaperLayout.tsx and src/layouts/EditorLayout.tsx define the two primary UI shells.

4. Desktop wallpaper layer

The desktop panel is not a normal floating window. It is attached to the Windows desktop shell using native Win32 interop in electron/native/wallpaper.ts with koffi, so it appears behind desktop icons and remains click-through. This is the key architectural boundary that makes the “today panel on the desktop” behavior possible.

5. Window management

electron/windows/windowManager.ts centralizes creation and control of the editor window and the wallpaper window. It coordinates route loading, visibility, focus behavior, and the “second instance brings editor forward” experience. The tray and IPC window handlers both delegate to this layer.

6. Data layer

Persistence is local-only via Prisma + SQLite. The Prisma schema lives in prisma/schema.prisma, migrations under prisma/migrations, and the runtime database file is stored in the app’s user data directory. The database models cover tasks, categories, notes, events, reminders, and settings.

7. Main-process database initialization

electron/database/init.ts and electron/database/client.ts handle creation and initialization of the SQLite database, including default settings and seed data. The repo also has explicit seed helpers such as seedStudentTasks.ts, plus CLI scripts for inspection and seeding, which indicates the database is a first-class subsystem rather than incidental storage.

8. IPC as the application boundary

All renderer-to-backend traffic goes through typed IPC. electron/preload.ts exposes a window.dayone bridge, and src/services/ipcClient.ts is the renderer-side wrapper. Channel names in electron/ipc/channels.ts separate concerns by domain: tasks, notes, categories, events, settings, wallpaper, and window operations.

9. IPC handlers and state invalidation

The handlers under electron/ipc/handlers/ implement CRUD and app actions in the main process. After mutations, the backend broadcasts data:changed so renderer views can refresh. This means UI state is driven by local DB changes plus explicit invalidation events rather than remote sync or shared memory.

10. Background services

The main process includes several long-lived services: startup registration with Windows, auto-updater support, display/monitor tracking, reminder notifications, wallpaper attach retries, and a watchdog to reattach after shell restarts or sleep. These services make the app behave like a persistent desktop companion rather than a normal single-window app.

11. Tray-centered app control

electron/tray.ts is the main user-control surface when the editor is hidden. It exposes app actions such as opening the editor, showing/hiding the wallpaper, navigating to feature sections, and toggling startup behavior. The close button does not terminate the app; tray state is part of the normal runtime model.

12. Build and packaging pipeline

The project is built with Vite for the renderer, TypeScript for Electron code, Prisma client generation, and electron-builder for NSIS packaging. The build output is split between dist/ for renderer assets and dist-electron/ for main/preload code, with packaged native dependencies such as Prisma’s engine and koffi unpacked so Electron can load them correctly.

13. Development mode differences

Development uses the Vite dev server plus Electron launch scripts, but the wallpaper injection path is intentionally disabled in dev. That means the true desktop-layer behavior is only exercised in installed production builds, which is an important distinction when diagramming runtime behavior versus development behavior.

14. Key end-to-end flows

The main architectural flow is: renderer UI action → preload bridge → IPC handler → Prisma/SQLite update → data:changed broadcast → renderer refresh. The desktop-specific flow adds another path: main process boot → wallpaper attach service → native Win32 desktop parenting → always-visible today panel. These two flows define the repo’s core behavior.