[PR #446] [CLOSED] Add a generic per-app properties map #475

New issue

Closed

opened 2026-10-15 13:00:51 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 13:00:51 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/wolf/pull/446
Author: @kmreisi
Created: 6/24/2026
Status: ❌ Closed

Base: stable ← Head: feature/app-properties-map

📝 Commits (1)

c92a969 feat(config): add generic per-app properties map

📊 Changes

4 files changed (+18 additions, -0 deletions)

View changed files

📝 src/moonlight-server/events/events.hpp (+3 -0)
📝 src/moonlight-server/events/reflectors.hpp (+4 -0)
📝 src/moonlight-server/state/configTOML.cpp (+4 -0)
📝 src/moonlight-server/state/serialised_config.hpp (+7 -0)

📄 Description

Draft — a generic per-app properties map so wolf can carry app-specific settings without per-app schema changes.

What

Apps gain an optional properties: map<string, string> that wolf itself does not interpret — the app image / runner does (e.g. steam_library_dirs, emulator firmware paths). It flows end-to-end:

BaseApp (TOML config) → events::App (runtime) → Reflector<App> (socket API /api/v1/apps), and round-trips back to TOML on save.

Why

External tooling (custom launchers / web UIs over the socket API) and app-specific runners need somewhere to attach settings meaningful only to a particular app, without growing wolf's core schema for each one. A generic string map keeps wolf agnostic while the app side interprets its own keys.

[[profiles.apps]]
title = "Steam"

[profiles.apps.properties]
steam_library_dirs = "/mnt/ssd/steam:/mnt/nas/steam"

Notes

Optional + defaults to empty → no behaviour change for existing configs.
An empty map round-trips to absent (no empty TOML table is written back).
First of a small series of hooks (this, plus client-settings policy fields) that let an external launcher/UI drive wolf entirely over the socket API.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/wolf/pull/446 **Author:** [@kmreisi](https://github.com/kmreisi) **Created:** 6/24/2026 **Status:** ❌ Closed **Base:** `stable` ← **Head:** `feature/app-properties-map` --- ### 📝 Commits (1) - [`c92a969`](https://github.com/games-on-whales/wolf/commit/c92a969236f976cd1a32c3af18b410c391b8e8cf) feat(config): add generic per-app `properties` map ### 📊 Changes **4 files changed** (+18 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `src/moonlight-server/events/events.hpp` (+3 -0) 📝 `src/moonlight-server/events/reflectors.hpp` (+4 -0) 📝 `src/moonlight-server/state/configTOML.cpp` (+4 -0) 📝 `src/moonlight-server/state/serialised_config.hpp` (+7 -0) </details> ### 📄 Description **Draft — a generic per-app `properties` map so wolf can carry app-specific settings without per-app schema changes.** ## What Apps gain an optional `properties: map<string, string>` that wolf itself does **not** interpret — the app image / runner does (e.g. `steam_library_dirs`, emulator firmware paths). It flows end-to-end: `BaseApp` (TOML config) → `events::App` (runtime) → `Reflector<App>` (socket API `/api/v1/apps`), and round-trips back to TOML on save. ## Why External tooling (custom launchers / web UIs over the socket API) and app-specific runners need somewhere to attach settings meaningful only to a particular app, without growing wolf's core schema for each one. A generic string map keeps wolf agnostic while the app side interprets its own keys. ```toml [[profiles.apps]] title = "Steam" [profiles.apps.properties] steam_library_dirs = "/mnt/ssd/steam:/mnt/nas/steam" ``` ## Notes - Optional + defaults to empty → no behaviour change for existing configs. - An empty map round-trips to *absent* (no empty TOML table is written back). - First of a small series of hooks (this, plus client-settings policy fields) that let an external launcher/UI drive wolf entirely over the socket API. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 13:00:51 +00:00