Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Notifications Plugin (@lapis-notes/notifications)

Source: packages/plugins/plugin-notifications/src/

Manifest: id plugin-notifications, version 0.0.1, min app version 1.7.7.

The notifications package is a required bundled plugin that owns app-level notification presentation for the shared renderer. It consumes the host-neutral app.notifications API from @lapis-notes/api and renders the visible in-app surfaces.

Responsibilities

  • Render transient information, warning, and error toasts for immediate feedback.
  • Register API-owned declarative status-bar items through app.statusBar for one stable low-priority background-progress item plus one bell or bell-count item for persisted notifications.
  • Open a scrollable notification center panel from a notifications-owned command instead of mounting popover UI into the compatibility status-bar host.
  • Persist durable notification history through AppDatabase as generated per-vault app state.
  • Mirror persisted app notifications through the neutral native desktop bridge when the active host advertises native notification support.

The plugin is intentionally UI-only. Background workers and first-party plugins report through app.notifications; they do not import this plugin or call Svelte components directly.

Progress Model

Progress follows VS Code’s split between status-bar progress and progress notifications:

  • Low-priority background work uses location: "status" and appears only in the status bar and notification center.
  • Work that was directly user-triggered, needs cancellation, or needs prominent details can use location: "notification" to also show a toast-style progress notification.
  • Work that should be observable by tests or diagnostics but not visible can use location: "silent".

Progress can be determinate (current / total), incremental (increment accumulated toward 100), or indeterminate. Cancellation is cooperative: the plugin exposes cancel actions, app.notifications aborts the task signal, and the task stops only when its implementation checks that signal.

Low-priority status progress is intentionally compact. The declarative status bar shows a single aggregated item with stable inline text, for example a task title plus percent or N more when multiple background tasks are running, and the shared status-bar renderer animates that item’s loader icon while work is active. File names, paths, and changing step descriptions stay out of the inline label and move into the status-item tooltip plus the notification center panel, which remains the click-open task list for active work. The plugin drives status-item visibility through scoped context keys under plugin.plugin-notifications.*, so progress, unread count, and fallback bell visibility all flow through the shared when evaluator instead of renderer-owned DOM toggles.

Persistence And Host Boundary

Persisted notifications are generated app state and must not be written into the user’s canonical vault files. Web and desktop hosts share the same in-app notification center and history. When the active desktop host advertises the notifications capability, the plugin mirrors persisted notification records through the neutral bridge; Electron main owns the OS notification API call. The plugin does not call Electron APIs directly, and transient toast-only notifications remain renderer-local.

First-Party Reporters

The first rollout wires these app-owned jobs into the shared progress API:

  • metadata cache load and rebuild
  • search index rebuild and semantic embedding refresh
  • Tasks plugin full task-cache rebuild
  • notebook command and render-service execution
  • official plugin registry install and update downloads
  • OPFS local-folder import