La v1.7.0 preguntaba por la clase `dark` de <html> y punto. En este mismo PC quedó la prueba de que eso miente en WebView2: estado.json con "dark": false y la app pintada de negro — barra clara sobre app oscura, el bug al revés. Ahora el reporte es a prueba de balas: - temaOscuro(): clase `dark` en <html> o <body>; si no está, la LUMINANCIA del fondo realmente pintado del body (funciona sea cual sea el mecanismo de tema); si tampoco, el color-scheme computado. Con el documento a medio crear devuelve null y el campo NO viaja (Rust conserva el último valor bueno) — nada revienta en frío. - Vigilancia segura: MutationObserver sobre <html> Y <body> (class/style/data-theme) registrado cuando existen, y dos re-reportes tras la carga por si el tema aterriza con la hidratación. Rust y la barra quedan como en v1.7.0 (un campo `dark` ausente ya significaba «conserva lo último»). El estado.json mentiroso se corrige solo con el primer reporte bueno. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
16 líneas
406 B
JSON
16 líneas
406 B
JSON
{
|
|
"name": "labstream-desktop",
|
|
"version": "1.7.1",
|
|
"private": true,
|
|
"description": "App de escritorio (Windows) que envuelve Labstream OS — cliente del servidor del NAS.",
|
|
"scripts": {
|
|
"icons": "tauri icon app-icon.png",
|
|
"dev": "npm run icons && tauri dev",
|
|
"build": "npm run icons && tauri build",
|
|
"tauri": "tauri"
|
|
},
|
|
"devDependencies": {
|
|
"@tauri-apps/cli": "^2"
|
|
}
|
|
}
|