# Komari Glassmorphism is a theme zip that treats averaging a counter as a bug > This is a Komari Monitor front-end theme shipped as an importable zip, and its changelog reads like a debugging diary: cumulative traffic that was being averaged down, a startup chain that failed entirely on one timeout, a ping loss grid where every cell showed the same colour. The glassmorphism is the visible part; the fixes are what the maintainer is actually shipping. **sanrokamlan-prog/komari-theme-Glassmorphism** — 🌌 Komari Monitor 毛玻璃主题 · 拓扑分析/性价比排行/健康摘要/审计日志/快照导出五大高级工具 · v3 服务层架构与安全加固 - Repository: https://github.com/sanrokamlan-prog/komari-theme-Glassmorphism - Stars: 377 · Forks: 53 - Language: Vue - License: MIT - Published: 2026-09-17 · Updated: 2026-09-17 · Language: en - Canonical page: https://hysenlabs.com/projects/sanrokamlan-prog-komari-theme-glassmorphism ## It is a theme archive, not something you deploy The positioning table in the README opens with the thing that trips people up, and it is worth reading before anything else. This is a Komari Monitor importable zip theme, not an ordinary web app deployment package. You drop it into a running Komari instance and it replaces the front end. The published artefact is named after the build rather than the version, in the form komari-theme-Glassmorphism-build-.zip. The rest of that table sets expectations for what it does with data. It prefers the Metric Store and falls back automatically to older interfaces, which is how one build stays compatible with Komari 1.2.x. Advanced tools are topology, a cost-performance ranking, a health summary, snapshot export and a visitor security audit. Visually it is glass cards over a dynamic background with light, dark and an automatic day-night mode keyed to Beijing time. The maintainer's own summary of the release is blunt about priorities: appearance is the shell. What v3 was for is folding metrics, ping, traffic, cost, health analysis and operations tooling into a panel you would actually open every day. There is also an embedded admin panel. The changelog records it switching back to the official web admin branch rather than depending on unmerged upstream pull requests, while keeping the full admin, terminal and management routes working under a subpath deployment. ## The startup chain was one serial chain and became four parallel ones Version 3.1.2 is the single most instructive entry in the changelog, and it describes a startup single point of failure that affected login state, node details and live connections at once. The old flow made the first ping call a gate. If it timed out or hit a moment of jitter, everything behind it never ran: public settings, user information, node data, and the WebSocket or polling that keeps the page live. One slow request and the application was dead. The fix is drawn in the README as a fan-out: ```text 健康检查 ─┐ 公开设置 ─┼─> 独立并行初始化 ─> 公共页面可用 用户信息 ─┤ ├─> WebSocket / HTTP 轮询恢复 节点数据 ─┘ └─> 全局错误提示与手动重试 ``` The behaviour table under it gives the mechanics: a five-second health-check timeout with at most three retries at increasing intervals, timed-out requests actively cancelled so nothing dangles, initialisation isolated with all-settled semantics rather than failing fast, and a failed first node fetch that still starts the realtime connection so data fills in when the network recovers. Two details show real care. The manual retry button guards against creating duplicate connections and timers, which is the obvious second bug once you add a retry. And the note at the end insists this is not a compatibility patch for particular Komari versions: slower backend responses make it easier to trigger, but the cause was an over-serial front-end chain and it is fixed by design. ## A cumulative counter cannot be averaged, and neither can a loss grid Two separate release entries fix the same class of error, and if you read nothing else in this changelog, read these. The first is version 3.3.7. The node detail history graph was showing cumulative upload and download traffic too low, because the values were downsampled with an average. An average of a monotonic counter is not a smaller counter, it is a different quantity. Those two series now take the last value in each time bucket, which preserves the semantics of a running total. Ordinary load metrics keep using averages, and the changelog is careful to say this does not affect real-time traffic, quota accounting, agent reporting or the backend's own bookkeeping. The second is version 3.1.4. The homepage's packet-loss grid was having its per-bucket values overwritten by a whole-period average, which made every cell the same value and the same colour. Each cell now reads the loss series from the metric store and is weighted by each ping task's actual sample count, so a bucket with two samples does not count as much as one with two hundred. Empty buckets still read as no data, and the negative-loss convention of older Komari releases is kept as a fallback. The newer entry adds a browser regression check on the aggregation parameters, and a related entry adds a deterministic regression test for the 5-day and 10-day colour boundaries. These are cheap to write and expensive to skip. ## The visitor audit takes fingerprints and promises not to take secrets The security-adjacent feature is the one that deserves the most careful reading, because a monitoring front end that records visitors is exactly the wrong place to be casual. It is built against an upstream change that the changelog is honest about: the audit records things the core is responsible for, namely the trusted source address, the user agent, the logged-in user identifier and the time. The theme's own contribution is a summary of restricted operations, covering the page, node, group, filter, view, tools and exports. The first page event carries a site-isolated session or browser fingerprint, plus hash digests of language, timezone, screen, hardware, automation, WebGL and WebRTC state. That is a deliberately broad set of signals and it is worth knowing it is being collected. The exclusion list is where the design shows its intent. The changelog states it does not upload passwords, cookies, tokens, query values, search terms, WebSSH commands, clipboard contents, raw ICE candidates or raw LAN addresses. The panel filters server-side, offers a structured view, and exports the current filter as JSON or CSV. It is also gated twice. Reporting and filtering switch on only when the core exposes the capability and the flag is enabled, and an older core does not receive unknown RPC requests at all, which is the right way to ship a theme against an upstream that has not landed the change yet. ## Colour is never the only signal, which is how this should be built Two entries treat accessibility as a requirement rather than a setting, and both are specific about how they avoid depending on hue. The colour-vision assistance mode uses a palette of blue, blue-green, orange, vermilion and magenta-red, and pairs it with four non-colour channels: lightness, dashed versus solid chart lines, a texture on the ping cells, and text and icon labels. The changelog states the point directly, which is that state is no longer distinguished by red and green alone. The node metric icons follow the same principle. CPU, memory, disk and traffic titles gained native line icons so the labels no longer needed a custom body injection script, the icon vocabulary matches the detail page, and the metric text and percentage stay in place. Small cards replaced the abbreviated C and M with fixed-size icons without growing the card, while keeping their accessible names. That last clause is the part that is easy to skip and expensive to lose. An icon with no accessible name is worse than an abbreviation. The test suite covers it, with desktop and mobile rendering assertions and accessibility regression coverage on the compact card mode. Seven Playwright visual scenarios back the whole thing: desktop and mobile, light and dark, card and list, the colour-vision mode, three globe layouts and the node detail page. ## Three globe renderers, and one of them dimmed the whole page The dependency list carries cobe for a dot-matrix globe, globe.gl for the three-dimensional one, three.js directly, and ECharts 6 for the charts. That is a heavy graphics stack for a monitoring panel, and the changelog is a record of what happens when three renderers have to coexist. Version 3.1.9 introduced forced cropping that made the real globe disappear or shrink to a small ball, and the tiled map's dark style applied to the whole document, dropping page opacity to 20 percent and darkening everything behind it. Version 3.2.0 reverted the crop, restored the earlier globe size and header height, and confirmed that tiled map, Cobe and the real globe all work on desktop and mobile with mobile using internal horizontal scrolling. Version 3.3.6 then fixed the tiled map forcing a fixed card arrangement and ignoring the overview card scheme, so that all three layouts read one configuration. There is more of the same kind of restraint in the performance entries. Past thirty nodes the first screen mounts cards lazily by viewport, fills in staggered when idle, and prioritises the target region during a fast scroll. Version 3.3.1 cut the card summary point count from six thousand to one hundred and fifty while leaving the full ping chart history intact, and fixed the home page staying alive under component caching so that node cards kept querying every node's ping from the detail page. The theme's own framing is that the expensive blur is limited to navigation, sidebars, tables and modals so that a dense node list does not pay for it. ## A cost estimator that says plainly that it is not a billing system A monitoring theme that shows you what your nodes cost is unusual, and this one is careful about what its numbers mean. The estimator takes a per-node traffic unit price saved locally in the browser, manual hours, one-off surcharges and a billing currency. It explicitly uses the probe's cumulative traffic snapshot and defines a terabyte as 1024 to the fourth power, so the arithmetic matches what the hosts report rather than what a vendor's dashboard assumes. Then the disclaimer, which is the important sentence: this is a pure front-end helper and not a billing system. Cumulative traffic can reset on a reboot or a network card change, and the manual hours and surcharges participate only in that one estimate. That honesty extends to the free-tier edge cases in version 3.3.3. Nodes whose price is minus one are the sentinel for a free node, and they were having monthly or annual periods appended to the word free, which is meaningless. The single-node remaining value for them now reads as none, while the aggregate total still computes as a numeric zero. And the exclude-free filter recognises both the price sentinel and the free-in-progress label, so an untagged free node no longer slips into a paid total. Version 3.3.1 fixed the mirror problem on the other side: renewing early or paying for several years at once was capping the remaining value at a single billing period. ## bun runs the scripts, Node is in engines, and two lint scripts are identical The build tooling is a small honest mess worth knowing about before you contribute. The package manager is pinned to a specific bun release, and the engine constraints require both a Node range and a bun range. Scripts are executed by bun directly rather than through a package runner, including the publish script and the one that syncs the embedded admin panel from upstream. The visual test script rebuilds and then runs Playwright, with a sibling that updates snapshots. Archiver is the dependency doing the zipping, and the parallel build uses a small run-all helper. Two scripts are byte-for-byte the same command: one named lint and one named lint:eslint, both running ESLint with fix and cache. That is a leftover from the config moving to the flat format, and it is the kind of thing that means a maintainer running the wrong one gets no error. The framework versions are ahead of most deployments rather than behind them, which cuts both ways: Vue Router 5, ECharts 6 and Vue 3.5 are all recent, and a Komari instance on an older toolchain is not the constraint here. On testing honesty, the visual regression suite uses entirely fictional fixed node, address, price and metric data, never contacts a real controller, and is excluded from the release archive. That is the correct arrangement: visual tests that touch production data are tests you eventually stop running. One more repository detail: there is an environment file committed at the root, alongside agent-facing documentation files and the theme manifest. ## Conclusion This theme suits someone running a Komari instance for a homelab or small fleet who wants topology, cost tracking and a health summary rather than a grid of CPU bars, and who reads release notes. It does not suit someone wanting a new monitoring backend, since it is a front-end for an existing one and several features wait on unmerged or unreleased core changes. Verify two things before installing: that your Komari core exposes the metric and visitor-audit capabilities the theme probes for, and whether your node count justifies a stack carrying three globe renderers and a 3D library. The current version is v3.3.7, the last release was on 2026-08-19, the last push on the repository was on 2026-09-12, and the licence is MIT. ## FAQ ### How do I install the Komari Glassmorphism theme? Download a release archive and import it into your running Komari Monitor instance. This is a front-end theme zip, not a standalone web app to deploy, and the published artefact is named komari-theme-Glassmorphism-build-.zip rather than carrying the version in its filename. ### Which Komari versions does the Glassmorphism theme support? It targets Komari 1.2.x, preferring the Metric Store and falling back to older interfaces automatically, including the legacy tags field and the records and ping fallbacks from 1.2.5. Several features detect capability fields and stay inactive against older cores. ### What does the visitor security audit in this theme collect? The core records the trusted source address, user agent, logged-in user identifier and time, and the theme records summaries of restricted operations. The first page event carries a site-isolated session or browser fingerprint plus hash digests of language, timezone, screen, hardware, automation, WebGL and WebRTC. It states it does not upload passwords, cookies, tokens, query values, search terms, WebSSH commands, clipboard contents, raw ICE candidates or raw LAN addresses. ### Does the Komari Glassmorphism theme work without colour? Yes. It has a colour-vision assistance mode using blue, blue-green, orange, vermilion and magenta-red, combined with lightness, dashed versus solid chart lines, a texture on the ping cells, text and icon labels, so state is not distinguished by red and green alone. Node metric icons also keep the text and percentage alongside the icon. ### Is the cost estimator in this theme a billing system? No, and the documentation says so. It is a front-end helper using per-node traffic unit price, manual hours, one-off surcharges and a currency, reading the probe's cumulative traffic snapshot with a terabyte defined as 1024 to the fourth power. Cumulative traffic can reset on a reboot or a network card change, and manual values feed only that estimate. ## Sources - [Issues](https://github.com/sanrokamlan-prog/komari-theme-Glassmorphism/issues) - [License: MIT](https://github.com/sanrokamlan-prog/komari-theme-Glassmorphism/blob/main/LICENSE) - [README](https://github.com/sanrokamlan-prog/komari-theme-Glassmorphism/blob/main/README.md) - [Releases](https://github.com/sanrokamlan-prog/komari-theme-Glassmorphism/releases) - [sanrokamlan-prog/komari-theme-Glassmorphism on GitHub](https://github.com/sanrokamlan-prog/komari-theme-Glassmorphism) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sanrokamlan-prog-komari-theme-glassmorphism