@vestra-player/sdk 1.6.0 → 1.6.2

package/CHANGELOG.md

@@ -1,20 +1,40 @@
 # Changelog
 
+## 1.6.2
+
+**Who must change: nobody, but check `TestHost` tests of a full sidebar or of `keepsRunning` with a background tab.** No change to the TypeScript API or the wire, `apiVersion` stays `vestra/1`, no new capability, no player version needed. `TestHost` follows player 0.7.3: it no longer refuses a ninth sidebar tab, and `keepsRunning` lists a sidebar panel only while its tab is the current tab, as `"its sidebar tab is the current tab"`. A test that expected `conflict` for a ninth tab, or `"a mounted panel"` for a sidebar panel, now fails.
+
+- **Sidebar tabs without a limit** (player 0.7.3; the player's [sidebar tabs design](https://github.com/vestrasys/vestra-player/blob/main/doc/architecture/sidebar-tabs.md)). The sidebar takes any number of tabs: the strip shows the tabs that fit and a `»` menu at its end lists all of them, the current one checked. Players 0.4.x to 0.7.2 refused a ninth tab with `conflict` (「侧栏最多 8 个页签」); player 0.7.3 never refuses a sidebar mount for that. `Panel.ready`, [Windows, panels, settings pages, dialogs and the OSD](docs/explanation/ui.md#shared-space) and `TestHost` say so. The SDK's copy of the player's Chinese texts (`HOST_ZH_HANS`) drops "The sidebar holds at most {} tabs", which the player no longer has.
+- **A background tab does not keep its plugin running** (player 0.7.3). The current tab keeps its plugin running as busy work; a sidebar panel never makes a plugin resident. A plugin whose sidebar panel is in a background tab, and that holds nothing else that keeps it running, goes to standby after the idle time like any idle plugin (stop reason `idle`); the player keeps its tab, with its title, in the strip and the `»` menu. Showing the tab starts the plugin again: `activate` runs and mounts the same panel (same file and component), which takes the tab over, and `Panel.ready` resolves again. The new process mounts with the properties its `activate` passes, so keep what the panel shows in session storage, the only state that survives standby, and restore it in `activate`. `Panel.state`, [Windows, panels…](docs/explanation/ui.md#panel), [How a plugin runs › Idle plugins are stopped](docs/explanation/plugins.md#idle-plugins-are-stopped) and [How the player runs and talks to plugins](docs/explanation/host-and-node.md) (the recorded `ui.mount`, the `panel_shown` wake) describe it. `TestHost.keepsRunning` lists `"its sidebar tab is the current tab"` while it is, and nothing for a background tab; `"a mounted panel"` is now for the bottom bar and the backdrop only.
+
+## 1.6.1
+
+**Who must change: nobody.** Docs only: no change to the TypeScript API, the wire or `TestHost`, `apiVersion` stays `vestra/1`, no new capability.
+
+- **Player versions corrected to 0.7.1.** Players 0.6.6 to 0.6.8 and 0.7.0 were internal builds that were never published; 0.7.1 is the first published player with the plugin supervisor, on-demand start for everyone and selectable Markdown. Every "player 0.6.6", "0.6.7", "0.6.8" and "planned for player 0.6.x" label now reads player 0.7.1, and `"minPlayerVersion": "0.6.8"` for selectable Markdown is now `"0.7.1"`. A plugin that set `"0.6.8"` keeps loading on 0.7.1 and later. The tables of [How the player runs and talks to plugins](docs/explanation/host-and-node.md), [How a plugin runs](docs/explanation/plugins.md#idle-plugins-are-stopped) and [Reference: limits › Plugin processes](docs/reference/limits.md#plugin-processes) show the 0.7.1 values in one column (start timeout 60 s and no start retry after it, 5 s stop grace, idle time 30 s, process budget, memory pressure). The entries of 1.5.58 and 1.6.0 are aligned the same way. Behaviour that player 0.6.4 already shipped (stop reasons, `InstallOptions.enabled`) is no longer called planned.
+- **Player release version** ([Reference: manifest › Player versions](docs/reference/manifest.md#player-versions), `AppInfo.version`, `minPlayerVersion`). From player 0.7.1, `plugin.app.version` and the version `minPlayerVersion` is compared with are the player release version, which can differ from the host binary version. Plugins compare against the release version.
+- **Windows GPU rendering** ([Reference: platforms](docs/reference/platforms.md), [Offer a GPU rendering switch](docs/how-to/gpu-rendering.md)). Windows has a GPU renderer since player 0.5.14 (Direct3D 12), experimental and off by default: **Video ▸ GPU Rendering (Experimental)** or `VESTRA_RENDER=gpu` turns it on. Software (CPU) mode, the default there, cannot run render options or plugin shaders (`unsupported`); platforms lists plugin shaders in their own row.
+- **The `lut3d` `.cube` format** (`VideoNode`, [Video and audio processing](docs/explanation/processing.md)). FFmpeg's `.cube` reader (`parse_cube` in `libavfilter/vf_lut3d.c`) reads the table: `LUT_3D_SIZE N`, optional `TITLE` and `DOMAIN_MIN`/`DOMAIN_MAX`, then N³ lines `r g b`, red changing fastest. Lines before `LUT_3D_SIZE` are skipped. Any other keyword after it, such as `MIN` or `MAX`, makes FFmpeg refuse the file, and the chain fails with "error running command (-12)". The player checks only the header.
+
 ## 1.6.0
 
-**Who must change: nobody.** No change to the TypeScript API, the wire or `TestHost`, `apiVersion` stays `vestra/1`, no new capability. New since 1.5.58 for plugin authors: Markdown the user can select and copy (`selectable` on `MarkdownView` and `MarkdownBlocks`, `plain` and `links` on `MarkdownBlock`, in the SDK's copy of the player's `@vestra/markdown.slint`; a plugin that uses them sets `"minPlayerVersion": "0.6.8"`), and, from player 0.6.7, plugins started on demand by default: a plugin starts on its first use and is stopped when idle, so `activate` can run many times and must never wait for its own commands or views (see 1.5.58). This is a minor release because it adds backward-compatible API and marks that milestone; nothing is removed or changed, and a plugin built with 1.5.x keeps working as it is.
+**Who must change: nobody.** No change to the TypeScript API, the wire or `TestHost`, `apiVersion` stays `vestra/1`, no new capability. New since 1.5.58 for plugin authors: Markdown the user can select and copy (`selectable` on `MarkdownView` and `MarkdownBlocks`, `plain` and `links` on `MarkdownBlock`, in the SDK's copy of the player's `@vestra/markdown.slint`; a plugin that uses them sets `"minPlayerVersion": "0.7.1"`), and, from player 0.7.1, plugins started on demand by default: a plugin starts on its first use and is stopped when idle, so `activate` can run many times and must never wait for its own commands or views (see 1.5.58). This is a minor release because it adds backward-compatible API and marks that milestone; nothing is removed or changed, and a plugin built with 1.5.x keeps working as it is.
 
-- **Selectable Markdown** (player 0.6.8; the SDK's `slint/vestra/markdown.slint` is synced with the player's). `MarkdownView` and `MarkdownBlocks` take `in property <bool> selectable: false`. With `true`, a paragraph, heading, list item or quote without links is shown as its plain text in a read-only selectable text field (right-click Copy / Select All, where Copy with nothing selected copies the whole block; Ctrl+C / Ctrl+A; each field is a Tab stop); a block with links keeps its clickable links, and its right-click menu copies it as plain text with each address after its link text, `text (url)`, plus Copy Link when it has one link. Code blocks are always selectable, whatever `selectable` says (in player 0.6.8 this applies to every plugin's Markdown). A selection stays inside one block and is lost when its row scrolls out of a `MarkdownView`. `MarkdownBlock` gains `plain: string` (the block as plain text) and `links: [string]` (its link addresses). Older players do not have the property: set `"minPlayerVersion": "0.6.8"` before using it. See [Reference: theme › Markdown](docs/reference/theme.md#markdown).
-- **Start retries corrected** ([How the player runs and talks to plugins](docs/explanation/host-and-node.md#the-start-deadline), [Reference: limits](docs/reference/limits.md#plugin-processes), [How a plugin runs](docs/explanation/plugins.md#restarts-activate-can-run-more-than-once)). 1.5.58 said a start that is not ready within the start timeout is tried up to three more times. That was player 0.6.6; from player 0.6.7 a timed-out start gets one try (60 s) and is not retried, and only a process that cannot be created is tried again (about 250 ms, 500 ms and 1 s apart).
+_Player versions aligned in 1.6.1: players 0.6.6 to 0.6.8 and 0.7.0 were internal builds, never published; 0.7.1 is the first published player with these features._
+
+- **Selectable Markdown** (player 0.7.1; the SDK's `slint/vestra/markdown.slint` is synced with the player's). `MarkdownView` and `MarkdownBlocks` take `in property <bool> selectable: false`. With `true`, a paragraph, heading, list item or quote without links is shown as its plain text in a read-only selectable text field (right-click Copy / Select All, where Copy with nothing selected copies the whole block; Ctrl+C / Ctrl+A; each field is a Tab stop); a block with links keeps its clickable links, and its right-click menu copies it as plain text with each address after its link text, `text (url)`, plus Copy Link when it has one link. Code blocks are always selectable, whatever `selectable` says (in player 0.7.1 this applies to every plugin's Markdown). A selection stays inside one block and is lost when its row scrolls out of a `MarkdownView`. `MarkdownBlock` gains `plain: string` (the block as plain text) and `links: [string]` (its link addresses). Older players do not have the property: set `"minPlayerVersion": "0.7.1"` before using it. See [Reference: theme › Markdown](docs/reference/theme.md#markdown).
+- **Start retries corrected** ([How the player runs and talks to plugins](docs/explanation/host-and-node.md#the-start-deadline), [Reference: limits](docs/reference/limits.md#plugin-processes), [How a plugin runs](docs/explanation/plugins.md#restarts-activate-can-run-more-than-once)). 1.5.58 said a start that is not ready within the start timeout is tried up to three more times. That was the internal build 0.6.6; from player 0.7.1 a timed-out start gets one try (60 s) and is not retried, and only a process that cannot be created is tried again (about 250 ms, 500 ms and 1 s apart).
 
 ## 1.5.58
 
-**Who must change: nobody.** Documentation only: no change to the TypeScript API, the wire or `TestHost`, `apiVersion` stays `vestra/1`, no new capability, no player version needed. Plugin authors should read what the player's new plugin supervisor does with their plugin (player 0.6.6, and the defaults planned for 0.6.7), and check that `activate` never waits for its own commands or views.
+**Who must change: nobody.** Documentation only: no change to the TypeScript API, the wire or `TestHost`, `apiVersion` stays `vestra/1`, no new capability, no player version needed. Plugin authors should read what the player's new plugin supervisor does with their plugin (written for the internal build 0.6.6 and the defaults planned for 0.6.7; player 0.7.1 is the first published player with it, with the 0.6.7 defaults), and check that `activate` never waits for its own commands or views.
+
+_Player versions aligned in 1.6.1: players 0.6.6 to 0.6.8 and 0.7.0 were internal builds, never published; 0.7.1 is the first published player with these features._
 
-- **The plugin supervisor, as a plugin sees it** ([How the player runs and talks to plugins](docs/explanation/host-and-node.md), [How a plugin runs](docs/explanation/plugins.md)). Player 0.6.6: a failed start is tried up to three more times; a built-in that crashes starts again by itself after 3 s, 6 s…; the fifth crash within 10 minutes stops a plugin until it is reloaded; an own process's JavaScript heap is capped at 512 MB (V8's heap only, not `Buffer` contents or addons), and passing it ends the process with "<name> ran out of memory"; a process that ended by itself gets no `runtime.stop`; without on-demand start a third-party plugin is listed as failed on its first crash, as before; at quit every plugin is stopped at once with 1 s in all; and two processes of one plugin never use its data directory at the same time. With on-demand start (lazy activation, `VESTRA_LAZY=1` in 0.6.6): a crashed plugin keeps its entries, shown disabled with the reason during a pause of 1 s, 2 s, 4 s…, and starts again on its next use (a resident plugin by itself); third-party plugins start a few at a time, clicks first; every start holds its clicks, resolutions, drops and view callbacks until `runtime.ready` (so an `activate` that awaits its own command or view callback waits until the start timeout); at most 64 are held per plugin, and one that cannot be taken is answered ("<name> is busy", "… could not start", "… is disabled") instead of dropped; busy work (a `busy` command, a dialog, a settings page shown, a resolution) keeps a plugin running with no time limit, and its idle time counts from when the work ends. Planned for player 0.6.7: on-demand start for everyone; a process budget for the machine's memory and the system's memory pressure put idle plugins in standby early, with the stop reason `idle`; idle time 30 s, start timeout 60 s, 5 s grace for a disable, uninstall, reload, upgrade or standby, a 5-minute cap on a player request awaiting the plugin's reply (a resolution; declared busy work stays uncapped), and a resident plugin never goes to standby. The source excerpts of host code that no longer exists (the lazy-activation trigger list, the 15-second activation record, the 250 ms idle poll, the stop's 5 ms poll) are replaced by descriptions of the current behaviour.
-- **[Reference: limits › Plugin processes](docs/reference/limits.md#plugin-processes)**: heap cap, start timeout, retries, start limit, restart pauses, stop graces, quit, idle time, request timeout, start slots (`min(4, max(2, cores / 2))` plus a reserve for clicks), held triggers (64), waiting starts (256), the process budget (`clamp(physical MiB / 2 × 0.30 / 85, 3, 16)`) and the memory pressure thresholds (both planned for 0.6.7), for player 0.6.6 and as planned for 0.6.7.
-- **`StopReason`** lists when each reason comes with the supervisor: `quit` also after a lost GPU device, `disable` clears session storage, `idle` also for the process budget and memory pressure (planned for 0.6.7; never for a busy plugin), `failed` also for a start timeout (possibly while `activate` runs) and, planned for 0.6.7, an unanswered request; a crash or running out of memory is no stop at all. The stop reasons are no longer described as planned: they shipped in player 0.6.4. **`PluginInfo.process`** `"idle"` also covers the pause after a crash before a plugin starts again. `Plugin`, `DisposeInfo` and [Store a plugin's data](docs/how-to/store-data.md) give the new stop graces.
-- **`appearance.changed` says what changed** (player 0.6.6): `"changed": ["theme"]` or `["language"]` beside `theme` and `language`. This SDK does not read it yet; a later release uses it so that a plugin woken by a language change no longer hears its unchanged theme once.
+- **The plugin supervisor, as a plugin sees it** ([How the player runs and talks to plugins](docs/explanation/host-and-node.md), [How a plugin runs](docs/explanation/plugins.md)). The internal build 0.6.6: a failed start is tried up to three more times; a built-in that crashes starts again by itself after 3 s, 6 s…; the fifth crash within 10 minutes stops a plugin until it is reloaded; an own process's JavaScript heap is capped at 512 MB (V8's heap only, not `Buffer` contents or addons), and passing it ends the process with "<name> ran out of memory"; a process that ended by itself gets no `runtime.stop`; without on-demand start a third-party plugin is listed as failed on its first crash, as before; at quit every plugin is stopped at once with 1 s in all; and two processes of one plugin never use its data directory at the same time. With on-demand start (lazy activation, `VESTRA_LAZY=1` in 0.6.6): a crashed plugin keeps its entries, shown disabled with the reason during a pause of 1 s, 2 s, 4 s…, and starts again on its next use (a resident plugin by itself); third-party plugins start a few at a time, clicks first; every start holds its clicks, resolutions, drops and view callbacks until `runtime.ready` (so an `activate` that awaits its own command or view callback waits until the start timeout); at most 64 are held per plugin, and one that cannot be taken is answered ("<name> is busy", "… could not start", "… is disabled") instead of dropped; busy work (a `busy` command, a dialog, a settings page shown, a resolution) keeps a plugin running with no time limit, and its idle time counts from when the work ends. Player 0.7.1 (planned as 0.6.7): on-demand start for everyone; a process budget for the machine's memory and the system's memory pressure put idle plugins in standby early, with the stop reason `idle`; idle time 30 s, start timeout 60 s, 5 s grace for a disable, uninstall, reload, upgrade or standby, a 5-minute cap on a player request awaiting the plugin's reply (a resolution; declared busy work stays uncapped), and a resident plugin never goes to standby. The source excerpts of host code that no longer exists (the lazy-activation trigger list, the 15-second activation record, the 250 ms idle poll, the stop's 5 ms poll) are replaced by descriptions of the current behaviour.
+- **[Reference: limits › Plugin processes](docs/reference/limits.md#plugin-processes)**: heap cap, start timeout, retries, start limit, restart pauses, stop graces, quit, idle time, request timeout, start slots (`min(4, max(2, cores / 2))` plus a reserve for clicks), held triggers (64), waiting starts (256), the process budget (`clamp(physical MiB / 2 × 0.30 / 85, 3, 16)`) and the memory pressure thresholds (both from player 0.7.1), for the internal build 0.6.6 and for 0.7.1 (planned as 0.6.7).
+- **`StopReason`** lists when each reason comes with the supervisor: `quit` also after a lost GPU device, `disable` clears session storage, `idle` also for the process budget and memory pressure (player 0.7.1; never for a busy plugin), `failed` also for a start timeout (possibly while `activate` runs) and, from player 0.7.1, an unanswered request; a crash or running out of memory is no stop at all. The stop reasons are no longer described as planned: they shipped in player 0.6.4. **`PluginInfo.process`** `"idle"` also covers the pause after a crash before a plugin starts again. `Plugin`, `DisposeInfo` and [Store a plugin's data](docs/how-to/store-data.md) give the new stop graces.
+- **`appearance.changed` says what changed** (player 0.7.1): `"changed": ["theme"]` or `["language"]` beside `theme` and `language`. This SDK does not read it yet; a later release uses it so that a plugin woken by a language change no longer hears its unchanged theme once.
 
 ## 1.5.57
 

package/dist/i18n.js

@@ -943,7 +943,6 @@ export const HOST_ZH_HANS = {
     sidebar: "侧栏",
     "video backdrop": "视频背景",
     "The {} is used by {}": "{}已被 {} 使用",
-    "The sidebar holds at most {} tabs": "侧栏最多 {} 个页签",
     "{} is resolved by {}": "{} 已由 {} 解析",
     "File type .{}": "文件类型 .{}",
     "Not available in fullscreen": "全屏时不可用",

package/dist/plugin/index.d.ts

@@ -22,7 +22,7 @@ export interface PluginInstance {
     /**
      * Stop the plugin: dispose the root scope, then stop the runtime.
      * `info.reason` (SDK 1.5.54) is why: the runner passes `runtime.stop`'s
-     * `data.reason` (planned for player 0.6.4), or `"host-lost"` when its input closed
+     * `data.reason` (player 0.6.4), or `"host-lost"` when its input closed
      * without a `runtime.stop`. It reaches `plugin.stopReason` and every
      * `onDispose` cleanup; a reason the SDK does not know reads as
      * `undefined`. A second call runs no cleanup again and keeps the first reason.

package/dist/plugin/testing.d.ts

@@ -2451,7 +2451,7 @@ export declare class TestHost implements Transport {
      * adds or upgrades the entry in {@link TestHost.packages} following the
      * player's source rules: the same source upgrades, another source needs
      * `replace` (`conflict` otherwise), a built-in id is `unsupported`. As
-     * player 0.6.4 (planned), the installed entry's `state` follows
+     * player 0.6.4 and later, the installed entry's `state` follows
      * {@link "@vestra-player/sdk"!InstallOptions.enabled}: a first install
      * runs, an update of a `disabled` entry stays `disabled` unless `enabled`
      * is `true`, and `enabled: false` installs it `disabled`. Set
@@ -2475,7 +2475,7 @@ export declare class TestHost implements Transport {
     readonly candidates: Map<string, PackageManifest>;
     /**
      * Which player's install rule `packages.install` plays. `true` (default,
-     * SDK 1.5.55): player 0.6.4 (planned), where an update or reinstall
+     * SDK 1.5.55): player 0.6.4 and later, where an update or reinstall
      * keeps a `disabled` plugin disabled unless the plugin passes
      * {@link "@vestra-player/sdk"!InstallOptions.enabled}. `false`: players
      * up to 0.6.3, where every install runs the plugin and `enabled` is
@@ -2782,12 +2782,18 @@ export declare class TestHost implements Transport {
     close(): void;
     /**
      * Why the player would keep this plugin running while nothing uses it
-     * (lazy activation, player 0.5.21), one line per reason, as the player's
-     * log says it: an event it listens to that is not one the player wakes
-     * it for (with what listens and where it was added), its mounted panel,
-     * its open windows. Empty: the player may stop it while idle and start
-     * it again on its next use. Filter chains, streams, jobs and the like
-     * (which also keep a plugin running) are not listed.
+     * (lazy activation, player 0.5.21), one line per reason: an event it
+     * listens to that is not one the player wakes it for (with what listens
+     * and where it was added), its panel in the bottom bar or the backdrop,
+     * its open windows (these as the player's log says them), and, from
+     * player 0.7.3, its sidebar tab while that is the current tab. The
+     * player counts the current tab as busy work, not as something live: it
+     * keeps the plugin running only while the tab is shown, and a sidebar
+     * panel in a background tab is no reason at all (the plugin may go to
+     * standby; showing the tab starts it again). Empty: the player may stop
+     * it while idle and start it again on its next use. Filter chains,
+     * streams, jobs and the like (which also keep a plugin running) are not
+     * listed.
      *
      * @capability None.
      * @since 1.5.40

package/dist/plugin/testing.js

@@ -314,8 +314,6 @@ const TEST_ZH_HANS = {
     "External SRT": "外部 SRT",
     "External ASS": "外部 ASS",
 };
-/** The player's limit of sidebar tabs. */
-const MAX_SIDEBAR_TABS = 8;
 /**
  * The player's refusal of a declaration (commands.rs `CommandError`): code
  * `invalid`, `conflict` or `limit`, its message prefixed as the player's.
@@ -3100,7 +3098,7 @@ export class TestHost {
      * adds or upgrades the entry in {@link TestHost.packages} following the
      * player's source rules: the same source upgrades, another source needs
      * `replace` (`conflict` otherwise), a built-in id is `unsupported`. As
-     * player 0.6.4 (planned), the installed entry's `state` follows
+     * player 0.6.4 and later, the installed entry's `state` follows
      * {@link "@vestra-player/sdk"!InstallOptions.enabled}: a first install
      * runs, an update of a `disabled` entry stays `disabled` unless `enabled`
      * is `true`, and `enabled: false` installs it `disabled`. Set
@@ -3124,7 +3122,7 @@ export class TestHost {
     candidates = new Map();
     /**
      * Which player's install rule `packages.install` plays. `true` (default,
-     * SDK 1.5.55): player 0.6.4 (planned), where an update or reinstall
+     * SDK 1.5.55): player 0.6.4 and later, where an update or reinstall
      * keeps a `disabled` plugin disabled unless the plugin passes
      * {@link "@vestra-player/sdk"!InstallOptions.enabled}. `false`: players
      * up to 0.6.3, where every install runs the plugin and `enabled` is
@@ -3983,12 +3981,18 @@ export class TestHost {
     }
     /**
      * Why the player would keep this plugin running while nothing uses it
-     * (lazy activation, player 0.5.21), one line per reason, as the player's
-     * log says it: an event it listens to that is not one the player wakes
-     * it for (with what listens and where it was added), its mounted panel,
-     * its open windows. Empty: the player may stop it while idle and start
-     * it again on its next use. Filter chains, streams, jobs and the like
-     * (which also keep a plugin running) are not listed.
+     * (lazy activation, player 0.5.21), one line per reason: an event it
+     * listens to that is not one the player wakes it for (with what listens
+     * and where it was added), its panel in the bottom bar or the backdrop,
+     * its open windows (these as the player's log says them), and, from
+     * player 0.7.3, its sidebar tab while that is the current tab. The
+     * player counts the current tab as busy work, not as something live: it
+     * keeps the plugin running only while the tab is shown, and a sidebar
+     * panel in a background tab is no reason at all (the plugin may go to
+     * standby; showing the tab starts it again). Empty: the player may stop
+     * it while idle and start it again on its next use. Filter chains,
+     * streams, jobs and the like (which also keep a plugin running) are not
+     * listed.
      *
      * @capability None.
      * @since 1.5.40
@@ -4012,7 +4016,13 @@ export class TestHost {
             if (!WAKE_EVENTS.includes(event))
                 for (const why of this.listeningWhy.get(event) ?? ["a listener"])
                     reasons.push(`listens to ${event}: ${why}`);
-        if (this.panel)
+        // A sidebar panel is never live (player 0.7.3): the current tab keeps
+        // the plugin running as busy work, a background tab not at all.
+        if (this.panel?.slot === "sidebar") {
+            if (this.layout.sidebar?.owner === 1)
+                reasons.push("its sidebar tab is the current tab");
+        }
+        else if (this.panel)
             reasons.push("a mounted panel");
         for (const [id, window] of this.windows)
             if (window.visible)
@@ -4234,8 +4244,8 @@ export class TestHost {
         "ui.mount": (p) => {
             if (this.panel)
                 throw new HostError("conflict", "owner already mounted");
-            // Like the player: one panel in the bottom bar and the backdrop, tabs
-            // in the sidebar (up to 8).
+            // Like the player: one panel in the bottom bar and the backdrop, any
+            // number of tabs in the sidebar (player 0.7.3; 0.4.x to 0.7.2 took 8).
             const holder = p.slot === "backdrop"
                 ? this.backdrop?.owner
                 : p.slot === "bottom"
@@ -4246,11 +4256,6 @@ export class TestHost {
                     this.#hostText(SLOT_LABELS[String(p.slot)]),
                     String(holder),
                 ]));
-            if (p.slot === "sidebar" &&
-                (this.layout.sidebar?.panels?.length ?? 0) >= MAX_SIDEBAR_TABS)
-                throw taken(this.#hostText("The sidebar holds at most {} tabs", [
-                    MAX_SIDEBAR_TABS,
-                ]));
             const properties = this.#initialValues(this.#shownValues(p.properties));
             this.#seeImages(properties);
             this.#resetWrites("$mount");

package/dist/plugin/types.d.ts

@@ -421,7 +421,7 @@ export interface Scope extends Disposable {
      * The plugin writes its cache file at once when the player crashed or
      * was killed, instead of waiting for the next periodic save. The cleanup
      * may get a {@link DisposeInfo}: `stopping` says the plugin itself stops
-     * (not a child scope), `reason` why (planned for player 0.6.4). Players
+     * (not a child scope), `reason` why (player 0.6.4). Players
      * whose SDK is older than 1.5.54 call the cleanup without an argument,
      * so read it with `?.`.
      * ```ts
@@ -524,9 +524,9 @@ export interface Scope extends Disposable {
  * (menus, windows, panels, filters, subtitle layers, snapshots, jobs,
  * resolvers, streams); pending requests then fail with `disabled` and the
  * root scope is disposed for local cleanup (timers, signals, sockets). A
- * process that has not exited after its grace is killed: 300 ms in player
- * 0.6.6 (2 s when it goes to standby), planned to be 5 s from player 0.6.7
- * (300 ms after a fault); at quit all plugins together get 1 s. Media the
+ * process that has not exited after its grace is killed: 5 s from player
+ * 0.7.1 (before it 300 ms; 300 ms after a fault); at quit all plugins
+ * together get 1 s. Media the
  * plugin opened with {@link Player.open} keeps playing.
  *
  * @example Write a minimal plugin with one menu item
@@ -591,7 +591,7 @@ export interface Plugin extends Scope {
  *
  * - `quit`: the player quits (or restarts after a lost GPU device). Every
  *   plugin is stopped at the same time, with 1 s in all (300 ms after a
- *   lost device; player 0.6.6).
+ *   lost device; player 0.7.1).
  * - `disable`: the user, or a plugin with `plugins.manage`, switched the
  *   plugin off. Its session storage is cleared.
  * - `uninstall`: the user uninstalls it.
@@ -604,25 +604,23 @@ export interface Plugin extends Scope {
  *   its menu items, keys, settings pages, resolvers and drop targets stay,
  *   and so does its session storage
  *   ([Idle plugins](../../docs/explanation/plugins.md#idle-plugins-are-stopped)).
- *   Only with on-demand start (lazy activation), off by default up to
- *   player 0.6.6 (`VESTRA_LAZY=1` turns it on) and planned for everyone in
- *   player 0.6.7. It comes after the idle time without use (60 s; 30 s
- *   planned for 0.6.7), right after a first run that holds nothing live,
- *   and when the player's limit on third-party processes or low system
- *   memory puts an idle plugin in standby early (planned for 0.6.7). A busy
- *   plugin never gets it; a resident one (it held something live when it
- *   became ready) only after the idle time, and from player 0.6.7 (planned)
- *   never.
+ *   Only with on-demand start (lazy activation): on for everyone from
+ *   player 0.7.1, off by default before it (`VESTRA_LAZY=1` turns it on).
+ *   It comes after the idle time without use (30 s; 60 s before 0.7.1),
+ *   right after a first run that holds nothing live, and, from player
+ *   0.7.1, when the player's limit on third-party processes or low system
+ *   memory puts an idle plugin in standby early. A busy plugin never gets
+ *   it; a resident one (it held something live when it became ready) never
+ *   from player 0.7.1 (before it, after the idle time).
  * - `failed`: the player stops it for a fault it can still tell the plugin
  *   about: a malformed request, an unreadable or oversized line, a start
- *   that is not ready within the start timeout (15 s; 60 s planned for
- *   player 0.6.7; the stop may come while `activate` still runs), an
- *   uncaught exception the shared process attributes to this plugin, and,
- *   planned for player 0.6.7, a request from the player (a resolution) it
- *   leaves unanswered for 5 minutes. From player 0.6.6 the player may
- *   start it again afterwards (a built-in or resident plugin by itself, a
- *   plugin with on-demand start on its next use), until the fifth fault
- *   within 10 minutes.
+ *   that is not ready within the start timeout (60 s from player 0.7.1;
+ *   the stop may come while `activate` still runs), an uncaught exception
+ *   the shared process attributes to this plugin, and, from player 0.7.1,
+ *   a request from the player (a resolution) it leaves unanswered for 5
+ *   minutes. From player 0.7.1 the player may start it again afterwards (a
+ *   built-in or resident plugin by itself, a plugin that has run before on
+ *   its next use), until the fifth fault within 10 minutes.
  * - `host-lost`: the plugin's runner saw its pipe to the player close
  *   without a stop: the player crashed or was killed. Requests are refused
  *   with `disabled`; clean up locally only. Player 0.6.4 sends `quit` on a
@@ -634,7 +632,7 @@ export interface Plugin extends Scope {
  * own process is killed because its input queue is full or a write to it
  * failed, when its own process fails to activate (the runner exits without
  * cleaning up), when the process ended by itself (it crashed, or its
- * JavaScript heap passed the 512 MB cap of player 0.6.6 and V8 ended it:
+ * JavaScript heap passed the 512 MB cap of player 0.7.1 and V8 ended it:
  * "ran out of memory"), and when the shared runner is restarted as a whole
  * (a hang, a fault it cannot attribute, an unreadable line of its own, a
  * member's full input queue, the runner exiting): every member is killed
@@ -1773,7 +1771,7 @@ export interface Ui {
      * the list on every streamed chunk keeps the scroll position and costs
      * little.
      *
-     * From player 0.6.8 both views take `selectable: true` (default `false`):
+     * From player 0.7.1 both views take `selectable: true` (default `false`):
      * the user can select and copy the text, one block at a time; blocks with
      * links keep their clickable links and copy as `text (url)`. Code blocks
      * are always selectable. `MarkdownBlock.plain` (the block as plain text)
@@ -2734,15 +2732,22 @@ export interface Panel extends View, Disposable {
      * A second sidebar panel is not refused: it resolves as another tab
      * (see {@link Panel.state}). Built-in plugins mount first at start-up,
      * so the playlist's tab is first and a built-in panel keeps its position.
+     * Behaviour from player 0.7.3: the sidebar takes any number of tabs; the
+     * strip shows the tabs that fit and a `»` menu lists all of them.
+     * Players 0.4.x to 0.7.2 refused a ninth tab with `conflict`. A plugin
+     * whose sidebar tab is in the background, and that holds nothing else
+     * that keeps it running, goes to standby when idle; showing the tab
+     * starts it again (see {@link Panel.state}).
      *
      * @throws `ui-prepare` (rejects) The Slint file does not compile, or a
      *   bound property is not declared on the bridge global; `message` has the
      *   diagnostics. (Players 0.4.0 and older also answer a taken bottom bar
      *   or sidebar with it.)
      * @throws `conflict` (rejects) Another plugin's panel holds the bottom bar
-     *   or the backdrop (shown, or being mounted), or the sidebar has all the
-     *   tabs it takes (8); `message` names the position and the holder
-     *   (「侧栏已被 vestra.playlist 使用」). Not an activation failure.
+     *   or the backdrop (shown, or being mounted); `message` names the
+     *   position and the holder (「底栏已被 vestra.playback 使用」). Not an
+     *   activation failure. Never for the sidebar (behaviour from player
+     *   0.7.3); players 0.4.x to 0.7.2 also refused a ninth sidebar tab.
      * @throws `busy` (rejects) The player is still preparing this plugin's
      *   previous mount, or its queue of mounts is full.
      * @throws `invalid` (rejects) `title` is longer than 128 bytes or has
@@ -2763,6 +2768,19 @@ export interface Panel extends View, Disposable {
      * only this plugin's own changes. A sidebar panel in a background tab
      * has `active: false`, `effective: false` and `reason: "otherTab"`.
      *
+     * Behaviour from player 0.7.3: a background tab does not keep the plugin
+     * running.
+     * If the panel is all that keeps it running, the plugin goes to standby
+     * after the idle time (stop reason `idle`): the player keeps its tab, with
+     * its title, in the strip and the `»` menu. When the user shows the tab,
+     * the player starts the plugin again; `activate` runs and mounts the same
+     * panel (same file and component), which takes the tab over, and
+     * {@link Panel.ready} resolves again. Anything the plugin kept only in
+     * memory is gone: restore the view from storage (session storage
+     * survives standby). While it is in the background, the player may also
+     * drop the panel's component and build it again from the bridge
+     * properties last written, as it does on any rebuild.
+     *
      * @throws Never; `null` stands for "not mounted".
      *
      * @since 1.5.2
@@ -4405,7 +4423,13 @@ export interface MainWindow {
  * @category Plugin
  */
 export interface AppInfo {
-    /** The player's version, e.g. `"1.0.0"`. */
+    /**
+     * The player's version, e.g. `"0.7.1"`. From player 0.7.1 this is the
+     * player's release version (the version of the published release), which
+     * can differ from the version of the host binary inside it. The player
+     * compares `minPlayerVersion` with this value, and plugins compare with
+     * it too.
+     */
     readonly version: string;
     /** Short git hash of the build, `null` when unknown. */
     readonly build: string | null;
@@ -8586,11 +8610,11 @@ export interface InstallOptions {
      * Built-in plugins always run (and cannot be installed over). A value
      * that is not a boolean is `invalid`.
      *
-     * Planned for player 0.6.4: older players ignore it and an install there
+     * Player 0.6.4 and later: older players ignore it and an install there
      * always runs the plugin, so after a committed install call
      * {@link Packages.setEnabled} when the state matters.
      *
-     * @player 0.6.4 (planned); older players ignore it (an install always
+     * @player 0.6.4; older players ignore it (an install always
      *   enables the plugin).
      */
     enabled?: boolean;
@@ -8639,8 +8663,8 @@ export interface PackageCandidate {
      * player). A reserved id (`vestra` or `vestra.*`, which every built-in
      * uses) fails with `reserved` (player 0.4.1; already when validated), as
      * only the player installs built-in plugins. An update keeps a disabled
-     * plugin disabled unless `enabled` says otherwise (planned for player
-     * 0.6.4; see {@link InstallOptions.enabled}).
+     * plugin disabled unless `enabled` says otherwise (player 0.6.4; see
+     * {@link InstallOptions.enabled}).
      *
      * @capability plugins.manage
      * @throws `invalid` (rejects) An option is malformed: a `source` the
@@ -8845,11 +8869,11 @@ export interface PluginInfo {
      * while the plugin is switched on but has no process. That is standby
      * with on-demand start (lazy activation): nothing used it for the idle
      * time, or the player's limit on third-party processes or low system
-     * memory stopped it early (planned for player 0.6.7); it starts again on its next
+     * memory stopped it early (player 0.7.1); it starts again on its next
      * use, and its menu items, keys, settings pages, resolvers and drop
-     * targets stay. From player 0.6.6 it is also the pause after a crash: a
+     * targets stay. From player 0.7.1 it is also the pause after a crash: a
      * built-in or resident plugin waiting to start again by itself, or a
-     * plugin with on-demand start whose commands are shown disabled with the
+     * plugin that has run before whose commands are shown disabled with the
      * reason until the pause ends. Absent in other states and from players
      * before 0.5.18. A change between the two alone does not fire
      * {@link Packages.onChange}; a plugin stopped by the start limit (five

package/dist/processing.d.ts

@@ -194,6 +194,39 @@ export type VideoNode =
      * 16 MiB) inside the plugin's package directory or data directory
      * after following links; a path with `[` or `]` is refused. Outside
      * those: `invalid`; a file that does not exist: `missing`.
+     *
+     * The player checks only that header; the table itself is read by
+     * FFmpeg's `.cube` reader (`parse_cube` in FFmpeg's
+     * [`libavfilter/vf_lut3d.c`](https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_lut3d.c)),
+     * which takes a subset of the
+     * Adobe/Resolve format:
+     *
+     * - Every line before `LUT_3D_SIZE N` is skipped (a `TITLE`, comments,
+     *   and also a `DOMAIN_MIN` or `DOMAIN_MAX` there, which then has no
+     *   effect).
+     * - After it, optional `TITLE`, `DOMAIN_MIN r g b` and
+     *   `DOMAIN_MAX r g b` lines (default `0 0 0` and `1 1 1`), blank
+     *   lines and `#` comments, then N³ data lines of three numbers
+     *   `r g b`, red changing fastest, then green, then blue.
+     * - Any other keyword after `LUT_3D_SIZE`, such as `MIN` or `MAX`, is
+     *   read as a data line, and FFmpeg refuses the file, as it does one
+     *   with fewer than N³ data lines. The chain then fails and the
+     *   player reports mpv's "error running command (-12)".
+     *
+     * ```text
+     * TITLE "Identity"
+     * LUT_3D_SIZE 2
+     * DOMAIN_MIN 0 0 0
+     * DOMAIN_MAX 1 1 1
+     * 0 0 0
+     * 1 0 0
+     * 0 1 0
+     * 1 1 0
+     * 0 0 1
+     * 1 0 1
+     * 0 1 1
+     * 1 1 1
+     * ```
      */
     file: string;
     /** How colours between the table's points are computed; `tetrahedral` is FFmpeg's default. */

package/dist/wire.d.ts

@@ -733,7 +733,7 @@ export declare function createWire(transport: Transport): {
         installed: (id: string) => Promise<InstalledPackage>;
         /**
          * `source` and `replace` are sent only when given (player 0.2.0);
-         * `enabled` only when given (planned for player 0.6.4, older players
+         * `enabled` only when given (player 0.6.4; older players
          * ignore it).
          */
         install: (token: string, expectedRevision: number, requestId: string, options?: {

package/dist/wire.js

@@ -343,7 +343,7 @@ export function createWire(transport) {
             installed: (id) => transport.request("packages.installed", { id }),
             /**
              * `source` and `replace` are sent only when given (player 0.2.0);
-             * `enabled` only when given (planned for player 0.6.4, older players
+             * `enabled` only when given (player 0.6.4; older players
              * ignore it).
              */
             install: (token, expectedRevision, requestId, options = {}) => transport.request("packages.install", {

package/llms.txt

@@ -1,6 +1,6 @@
 # Vestra Player SDK
 
-> @vestra-player/sdk 1.6.0: write plugins for Vestra Player in TypeScript (plugin API `vestra/1`). A plugin is a folder with `manifest.json` and an entry module whose default export `activate(plugin)` the player calls. The documentation is a tree of short pages read by path, like `go doc`: the same pages and API as https://vestrasys.github.io/vestra-player-sdk/.
+> @vestra-player/sdk 1.6.2: write plugins for Vestra Player in TypeScript (plugin API `vestra/1`). A plugin is a folder with `manifest.json` and an entry module whose default export `activate(plugin)` the player calls. The documentation is a tree of short pages read by path, like `go doc`: the same pages and API as https://vestrasys.github.io/vestra-player-sdk/.
 
 ## Read the documentation
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vestra-player/sdk",
-  "version": "1.6.0",
+  "version": "1.6.2",
   "description": "Plugin API types, test host and plugin CLI for Vestra Player (apiVersion vestra/1)",
   "license": "Apache-2.0",
   "repository": {