What can plugins add to Phials?
Plugins add capabilities to an existing Phials workflow. A plugin can contribute one capability or combine several of them under one identity, release, settings area, and permission set.
Choose the capability that directly produces the outcome you need. The public SDK name in the second column is the typed registration contract you will use after the concept is clear.
| Outcome | Public SDK entry point | Continue with |
|---|---|---|
| Add actions to the Command Bar, Path Bar, context menus, and keyboard shortcuts | CommandProvider | Add commands |
| View or edit supported files, optionally with thumbnails and toolbar controls | PreviewProvider | Build file viewers and editors |
| Extract structured information from files and make it available to Phials | MetadataProvider | Extract file metadata |
| Add another presentation of an Explorer tab’s current location | FileBrowserViewProvider | Build file views |
| Add a tool surface to a left, right, or bottom dock or to a center tab | ModuleProvider | Add panels and tabs |
| Let users configure plugin behavior | PhialsPlugin.settings and optional settingsComponent | Add plugin settings |
| Supply a light or dark appearance for Phials | Plugin theme assets | Create themes |
These capabilities compose. For example, a plugin for a specialized document format might contribute:
- a file viewing and editing capability for the document itself;
- a file metadata capability for author, revision, and status fields;
- commands for document-specific actions;
- settings for default display behavior.
That is still one plugin. Users install, review, enable, update, and remove it as one artifact.
Connect capabilities to Phials services
Providers describe what Phials should add. The runtime Plugin API lets the plugin perform supported work while those capabilities run.
Depending on the workflow, a plugin can:
- work with files and folders through typed, permission-aware operations;
- read the current app or Explorer context exposed by the SDK;
- store configuration, key-value state, or structured plugin data;
- listen for supported Phials events and emit namespaced plugin events;
- open dialogs and show notifications;
- open or focus a center tab supplied by a panel and tab capability.
These are services rather than additional plugin categories. Start with the visible capability, then use only the services it needs. The Work with Phials section covers those shared contracts.
Choose a focused capability set
A useful first design can be stated in one sentence: “When this file or context is present, the plugin lets the user achieve this outcome.” That statement helps keep registration and permissions narrow.
Before adding another provider, ask:
- Does this create a distinct user-visible capability, or is it supporting logic for an existing one?
- Does it belong under the same plugin identity and release lifecycle?
- Can it reuse the plugin’s settings and data without coupling unrelated workflows?
- Does it require a new permission, and can the user understand why?
Prefer one cohesive plugin with several cooperating providers over several packages that must be installed together. Prefer separate plugins when their purpose, release schedule, trust requirements, or ownership can stand alone.
Next, see Understand plugins, capabilities, and providers for how these pieces appear in a plugin definition.