Skip to main content

Application Integration

In Ideal, applications are fully capable programs — they sync data, render interfaces, and process information. The difference from a traditional desktop is that instead of each running as an isolated program with its own window, applications integrate into the desktop shell. They provide views and actions that become part of the explorer itself.

How Applications Participate​

An application in Ideal contributes to the desktop through three roles, which may coexist in a single application or be provided separately:

Views​

A view determines how a typed folder or a file is presented in the explorer. A calendar application provides a view that renders event files as a monthly or weekly timeline. A music application provides a view that presents an audio collection as a library with artists and albums. A note-taking application provides a view that displays a folder of text documents with titles and previews.

Views are contextual — they activate based on the type of data the user is looking at. The user doesn't launch a calendar application; they navigate to their events folder and the calendar view activates. The user doesn't open a music player; they navigate to their collection and the player view renders it.

Actions​

Actions are operations that applications make available on data. A mail application provides reply, forward, archive. A document application provides annotate, export, print. A code editor provides build, run, debug.

The critical design decision is that actions are integrated into the desktop, not confined to an application's own interface. This means:

  • A PDF's annotation action is available whether the PDF is a standalone file, an email attachment, or a document inside a project folder.
  • A code file's build action is available whether you're browsing the source tree or looking at a recent changes view.
  • An image's resize action is available in a gallery, in a document, or as a loose file on the desktop.

Actions follow the data, not the application. The desktop presents them in context — in toolbars, context menus, or keyboard shortcuts — grouped by what they do, not by which application provides them.

Background Services​

Some applications need to do work in the background — syncing email from a remote server, indexing music metadata, watching for file changes in a project. These background services (daemons) run independently of whether the user is currently looking at the relevant data.

A mail daemon syncs with an IMAP server and writes new messages to the Maildir folder. A calendar daemon syncs with a CalDAV server and updates event files. A music service scans for new tracks and maintains metadata. These services keep data up to date, and the desktop reflects those changes in the view accordingly.

Standard and Domain Actions​

Actions are divided into two categories:

Standard Actions​

A set of common verbs that behave consistently across all data types:

  • open / view
  • edit
  • rename / move / copy / delete
  • share / export
  • search
  • properties / info

These are always available and always in the same place in the interface, regardless of the data type.

Domain Actions​

Operations specific to a kind of data, provided by the application that handles it:

  • Email: reply, forward, archive, mark as read
  • Audio: play, pause, add to queue, shuffle
  • Code: build, run, debug, commit
  • Documents: annotate, sign, convert

Domain actions appear alongside standard actions in the desktop's interface, grouped by what they do. The user sees a unified set of things they can do with their data — the distinction between standard and domain actions is architectural, not visible.

Search and Indexing​

Applications participate in a global search index. Each application can act as an indexer for the data types it understands:

  • When a file changes, the system notifies the appropriate indexer.
  • The indexer extracts structured fields (sender and subject for email, title and artist for music) and full-text content.
  • A default indexer handles plain text extraction for types without a specialized application.

This enables searches across all data from a single interface — from:alice topic:project finds emails, artist:radiohead year:1997 finds music — without the user needing to know which application indexes what.