Bundled Plugins

Every user-facing feature ships as a plugin — one Qt plugin DLL/SO per feature in plugins/, loaded at runtime. The host has no compile-time knowledge of any of them; they coordinate only through the module context (events and services). This is the same mechanism your own SDK plugins use.

Plugin	Plugin id	What it does
Overlay	framelift.overlay	Playback-controls HUD, idle screen, and on-screen notifications.
Playlist	framelift.playlist	Directory scanning, the playlist panel, and file navigation.
History	framelift.history	Recently-played entries with saved resume positions.
SettingsMenu	framelift.settings_menu	The settings pages, plugin catalogue, and keybind editor.
DebugOverlay	framelift.debug_overlay	Live playback and runtime diagnostic overlay.
Benchmark	framelift.benchmark	Performance benchmark overlay and system stats.
RemoteStream	framelift.remote_stream	Remote URL entry and HTTP/HTTPS/RTSP streaming.
ContextMenu	framelift.context_menu	A shared right-click menu surface other plugins extend via a service.

Toggling them

Because they are ordinary plugins, any of these can be disabled at runtime from Settings → Plugins (which writes plugins.ini), or by deleting the plugin DLL/SO from plugins/. The SettingsMenu, host UI, and playback paths are the ones most features depend on, so disabling them affects the most.

How they cooperate

A few representative interactions illustrate the events-first design:

• History publishes an OpenFileRequestEvent when you pick an entry; Playlist subscribes and actually opens the file.
• Playlist publishes FileOpenedEvent / FileEndedEvent; History consumes them to update entries and resume positions.
• Any plugin publishes a NotificationEvent; Overlay subscribes and shows it.
• SettingsMenu renders other plugins' pages without knowing their types, via the ISettingsRegistry service.

See Cross-Plugin Communication for the mechanics.