mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-11-14 21:04:04 +01:00
LGUG2Z
fa2d630701
The Windows gate showed that the bar cannot open a window in the golden guest (no OpenGL 2.0: "egui_glow requires opengl 2.0+"). The scenario now reads the bar's own output (`classify`): that exact failure turns the window, stays-alive and daemon-restart checks into visible `skipped: guest has no OpenGL 2.0` lines (counted in `result.json` and printed as `skipped: N` by the runner); the schema equality, "the bar reads its configuration" (real: the configuration is parsed before the window), `komorebic state` and `stop --bar` stay checks; any other early exit of the bar (a configuration error, a panic) is a failure with the bar's output in the message, and a bar that opens its window gets the full walk as before. Unit tests for `classify` run with the runner tests. komorebi-bar-core gets tests/config.rs: windows-only widgets and the `mouse` block are accepted on every platform, `supported()/unsupported()/enabled()` name and skip what the platform cannot run (D-coord-1), a Command mouse message is a plain string and the tagged form is rejected (the e2e finding), the network widget accepts `default_interface_options` and the old key names, layouts read from their names, `KomobarConfig::read` fills the frame and refuses a non-json file. The warning text itself is not asserted (no tracing subscriber in the core). docs/dev/bar-e2e.md records the limitation and an analysis of getting rendering into the guest (wgpu with the WARP adapter recommended; a mingw Mesa is not offered by nixpkgs); nothing was added. Verified: runner and library tests (161 passed), ruff clean on the scenario (three older findings in other files are not mine), bar-core native tests 3 unit + 7 oracle + 6 config. Windows clippy and the macOS check: see the report. The scenario itself was not run.