3 Commits

Include renames

Author	SHA1	Message	Date
Sansan	4a45e8516d	Send the play queue ID to the server ... The server keeps a play queue per client, identified by the X-Queue-Id header. The client sends the ID it has for the selected server with every request and keeps the one in each response, which is new after a reset or a sync. The IDs are saved per server in the [queues] section of settings.cfg, so the game goes on with the same queue after a restart. HttpTransport now passes the response headers on to the client.	2026-10-07 21:23:37 +02:00
Sansan	f7619baf34	Use /api/v1 with token authentication and typed responses ... Closes #38, #39 and #40; adds the client side of #41. - Every request goes to /api/v1. MusicServerClient gets a token with Settings.api_password the first time one is needed, reuses it, and on a 401 gets a new one and sends the request once more. Switching server gets a new token too. Callers never see the token. - Sync is started with POST, as MusicServer 5.0 requires. - The client has every endpoint in the server's OpenAPI spec, including statistics, soundtracks and songs by UUID, version, downloads and tokens. - tools/generate_api_types.gd generates a typed class per schema in server/openapi.json into server/generated/. Song info, statistics and versions are passed to callers as these classes. A list the server sends as null is an empty list. - FakeHttpTransport hands out tokens and answers 401 without one, so every test goes through the token flow. New tests cover the token handling, every endpoint and each generated class.	2026-10-06 22:45:28 +02:00
Sansan	d77b72159d	Sort the scripts and scenes into folders ... main/ holds the main window and top bar, quiz/ the quiz and its parts, player/ the music player, popups/ every popup and what they share, data/ the songs, players, playlist and settings, server/ the MusicServer client, common/ the list row and GameLog, and themes/ the themes and style boxes.	2026-10-06 11:57:29 +02:00