Apps and files

Open a book, highlight a paragraph and add a note. Search for a phrase from that note later, open the result in the reader, or ask an authorised agent to list the annotations. The book and note remain the same items through every route.

The reader is a lens onto the work. It does not own the work.

Native apps describe what you can see and do

A native app tells the desktop about concrete items such as books, notes, messages and annotations. It also names their actions: Add note, Rename, Go to page, Post comment.

The desktop uses that description to provide search, history, undo, collaboration, permissions and accessibility. A toolbar button, search result, keyboard command, assistive tool and authorised agent all reach the same named action. There is no second, more powerful interface hidden behind the pixels.

Common interface parts belong to the desktop too. Tabs can group a terminal, PDF and browser in one frame because the apps do not each own a separate tab system. Appearance follows the person’s theme rather than forty unrelated app themes.

Open is not install

Native apps share the system toolkit and services, so the app-specific download can remain small. Select Open and the desktop fetches the app, verifies it and runs it in the current workspace. Adding an app executes no installer hooks and does not modify a shared system directory.

Select Keep on this device to retain the app for offline or frequent use. Removing it removes the software and leaves the work it created. Updates replace the app atomically and never widen its existing permissions.

Normal Linux apps remain normal Linux apps

Flatpaks and other Linux apps run beside native apps. They keep the toolkits and file formats they were written for. The workspace still confines what they can reach, and system file pickers hand them the files you choose.

An app that does not expose semantic items cannot gain structured history or fine-grained collaboration by magic. The desktop shares its rendered surface when people need to work with it together, while native apps exchange state and render locally for every participant.

Windows apps use the first compatibility route that works

Windows applications open through the integrated Wine layer, and Windows games use integrated Proton profiles. An application that needs Windows itself opens through the side-by-side Windows VM; its application window appears beside the rest of the workspace instead of inside a second desktop.

The launcher labels the active route and keeps each application’s compatibility environment separate. Files, clipboard contents, devices and network access cross only when they are granted. Read Windows application compatibility for the complete fallback order and migration behaviour.

Defaults belong to people

Your personal default app opens a file unless the workspace specifies a shared choice. Workspace settings show Workspace choice and Your choice side by side. Removing an app never strands its files: the desktop offers another app that understands the format or lets you choose one.