mirror of
https://github.com/ChuckBuilds/LEDMatrix.git
synced 2026-10-04 14:25:08 +00:00
* refactor: remove the skin system Skins never rendered with the current scoreboard plugins: the only hook was SportsCore._render_game in src/base_classes, which no plugin builds on, so the UI and store already treated them as unsupported. The owner decided on 2026-09-23 to remove them outright. Removed src/skin_system/ (runtime, base class, fixtures), skins/, scripts/validate_skin.py and their tests; the store's "type": "skin" installer, uninstaller and hide/refuse filters (the official registry lists no skins); SchemaManager.inject_skin_selector; and GET /api/v3/skins. Stored skin/skin_options config values are handled in the next commit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(config): drop retired skin/skin_options keys instead of validating them A config.json written while the skin system existed can carry skin and skin_options in any plugin section, and most plugin schemas set additionalProperties: false. They are no longer core plugin properties; RETIRED_PLUGIN_KEYS in schema_manager lists them and drop_retired_plugin_keys removes them (unless the plugin's own schema declares the name) in prepare_plugin_config, which loading, hot reload, GET /plugins/config and both web saves already share, and in validate_config_against_schema for callers that validate a raw section. POST /plugins/config and /config/main also drop them from the stored section they merge into, so they leave config.json on the next save. Tests cover the load path (real PluginManager.load_plugin: no schema warning, not degraded), raw and prepared validation, validate_all_plugin_configs, and the JSON, form and /config/main saves. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor: remove the unused src/base_classes package No scoreboard plugin builds on src.base_classes: the nine monorepo scoreboards ship their own sports.py and share code through src/common (docs/SPORTS_UNIFICATION.md), and none of the third-party registry plugins imports it. The one import anywhere, baseball-scoreboard's rankings_manager.py, is a lazy import of ESPNDataSource in a class nothing instantiates. Removed the package and the eight test files that only tested it (test_api_extractors, test_data_sources, test_sports_base_characterization, test_sports_capabilities, test_sports_core_promotions, test_sports_logo_cache_bounded, test_sports_modes_promotions, test_sports_odds_fanout). test_common_is_hardware_free no longer lists src.base_classes as a forbidden import, and comments in sports_helpers.py and base_odds_manager.py stop pointing at it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs: drop the skin system and src/base_classes from the docs Deletes docs/SKIN_SYSTEM.md and docs/CREATING_SKINS.md and every link to them (docs/README.md, README.md, PLUGIN_DEVELOPMENT_GUIDE.md, the /skins section of REST_API_REFERENCE.md), the skin section of CLAUDE.md and the term in PRODUCT.md. SPORTS_UNIFICATION.md now says src/base_classes was removed and shared code lives in src/common, in the Layering section and the view-model-contract rule. Other docs stop pointing at the removed package. CHANGELOG records both removals under Unreleased. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(store): hide and refuse registry entries that aren't plugins The skin filters went with the skin system, but a custom registry can still list "type": "skin" entries, and installing one as a plugin would unpack it into the plugins directory. PluginStoreManager.is_plugin_entry() (a missing type means plugin) now hides non-plugin entries from the store and custom-registry listings, and install refuses them, in the route with a clear 400 and in _install_plugin_impl for any other caller. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
145 lines
5.0 KiB
Markdown
145 lines
5.0 KiB
Markdown
# Core Plugin Properties
|
|
|
|
## Overview
|
|
|
|
The LEDMatrix plugin system automatically manages certain core properties that are common to all plugins. These properties are handled by the system and don't need to be explicitly defined in plugin schemas.
|
|
|
|
## Core Properties
|
|
|
|
The following properties are automatically managed by the system (the list
|
|
is `CORE_PLUGIN_PROPERTIES` in `src/plugin_system/schema_manager.py`):
|
|
|
|
1. **`enabled`** (boolean)
|
|
- Default: `true`
|
|
- Description: Enable or disable the plugin
|
|
- System-managed by PluginManager
|
|
|
|
2. **`display_duration`** (number)
|
|
- Default: `15`
|
|
- Range: 1-300 seconds
|
|
- Description: How long to display the plugin in seconds
|
|
- Can be overridden per-plugin
|
|
|
|
3. **`live_priority`** (boolean)
|
|
- Default: `false`
|
|
- Description: Enable live priority takeover when plugin has live content
|
|
- Used by DisplayController for priority scheduling
|
|
|
|
4. **`vegas_width_pct`**, **`vegas_overflow`**, **`vegas_max_width_screens`**
|
|
(untyped; no default)
|
|
- Description: Vegas mode tuning for this plugin — card width as a
|
|
percentage of the panel, `"rotate"` or `"truncate"` on overflow, and the
|
|
widest the card may be in screens
|
|
- Read by `src/vegas_mode/plugin_adapter.py` and `BasePlugin`, which
|
|
validate the values themselves and ignore a bad one with a log line
|
|
|
|
`skin` and `skin_options` were core properties until the skin system was
|
|
removed. A plugin config saved with them still loads and saves; the keys are
|
|
dropped on the next save (see `RETIRED_PLUGIN_KEYS` in `schema_manager.py`).
|
|
|
|
## How Core Properties Work
|
|
|
|
### Schema Validation
|
|
|
|
During configuration validation:
|
|
|
|
1. **Automatic Injection**: Core properties are automatically injected into the validation schema if they're not already defined in the plugin's `config_schema.json`
|
|
2. **Removed from Required**: Core properties are automatically removed from the `required` array during validation, since they're system-managed
|
|
3. **Default Values Applied**: If core properties are missing from a config, defaults are applied automatically:
|
|
- `enabled`: `true` (matches `BasePlugin.__init__`)
|
|
- `display_duration`: `15` (matches `BasePlugin.get_display_duration()`)
|
|
- `live_priority`: `false` (matches `BasePlugin.has_live_priority()`)
|
|
|
|
### Plugin Schema Files
|
|
|
|
Plugin schemas can optionally include these properties for documentation purposes, but they're not required:
|
|
|
|
```json
|
|
{
|
|
"properties": {
|
|
"enabled": {
|
|
"type": "boolean",
|
|
"default": true,
|
|
"description": "Enable or disable this plugin"
|
|
},
|
|
"display_duration": {
|
|
"type": "number",
|
|
"default": 15,
|
|
"minimum": 1,
|
|
"maximum": 300,
|
|
"description": "Display duration in seconds"
|
|
},
|
|
"live_priority": {
|
|
"type": "boolean",
|
|
"default": false,
|
|
"description": "Enable live priority takeover"
|
|
}
|
|
},
|
|
"required": [] // Core properties should NOT be in required array
|
|
}
|
|
```
|
|
|
|
**Important**: Even if you include core properties in your schema, they should **NOT** be listed in the `required` array, as the system will automatically remove them during validation.
|
|
|
|
### Configuration Files
|
|
|
|
Core properties are stored in the main `config/config.json` file:
|
|
|
|
```json
|
|
{
|
|
"my-plugin": {
|
|
"enabled": true,
|
|
"display_duration": 20,
|
|
"live_priority": false,
|
|
"plugin_specific_setting": "value"
|
|
}
|
|
}
|
|
```
|
|
|
|
## Implementation Details
|
|
|
|
### SchemaManager
|
|
|
|
The `SchemaManager.validate_config_against_schema()` method:
|
|
|
|
1. Injects core properties into the schema `properties` if not present
|
|
2. Removes core properties from the `required` array
|
|
3. Validates the config against the enhanced schema
|
|
4. Applies defaults for missing core properties
|
|
|
|
### Default Merging
|
|
|
|
When generating default configurations or merging with defaults:
|
|
|
|
- Core properties get their system defaults if not in the schema
|
|
- User-provided values override system defaults
|
|
- Missing core properties are filled in automatically
|
|
|
|
## Best Practices
|
|
|
|
1. **Don't require core properties**: Never include `enabled`, `display_duration`, or `live_priority` in your schema's `required` array
|
|
2. **Optional inclusion**: You can include core properties in your schema for documentation, but it's optional
|
|
3. **Use system defaults**: Rely on system defaults unless your plugin needs specific values
|
|
4. **Document if included**: If you include core properties in your schema, use the same defaults as the system to avoid confusion
|
|
|
|
## Troubleshooting
|
|
|
|
### "Missing required property 'enabled'" Error
|
|
|
|
This error should not occur with the current implementation. If you see it:
|
|
|
|
1. Check that your schema doesn't have `enabled` in the `required` array
|
|
2. Ensure you're using the latest version of `SchemaManager`
|
|
3. Verify the schema is being loaded correctly
|
|
|
|
### Core Properties Not Working
|
|
|
|
If core properties aren't being applied:
|
|
|
|
1. Check that defaults are being merged (see `save_plugin_config()`)
|
|
2. Verify the schema manager is injecting core properties
|
|
3. Check plugin initialization to ensure defaults are applied
|
|
|
|
|
|
|