glzr-io/zebar

Description Some tray icons are not detected by the systray provider, even though they are visible in the Windows system tray. Specifically, Toggl Track's tray icon is completely absent from output.systray.icons. Steps to Reproduce Have Toggl Track running with a visible tray icon in Windows Add systray: { type: 'systray' } to the provider group Log output.systray.icons — Toggl Track is missing from the list Expected Behavior All visible tray icons in Windows should be detected by the systray provider. Possible Root Cause Toggl Track may send Shell_NotifyIcon with a zero window handle and no GUID, causing it to fail the StableId assignment in systray.rs and be silently dropped: ust let stable_id = icon_data.guid.map(StableId::Guid).or({ match (icon_data.window_handle, icon_data.uid) { (Some(handle), Some(uid)) => Some(StableId::HandleUid(handle, uid)), _ => None, // <-- silently dropped } })?; Environment Zebar v3.x Windows (laptop) Additional Context The icon is visible in the

Describe the bug My widget polls a local app on another port (e.g. localhost:8085) every second. After a while, the values stop updating. There are no errors and the polling loop keeps running, but the response is stale. In DevTools, the request changes from a normal 200 OK to: 200 OK (from service worker) and no longer has a remote address. The Date header is also from the previous response. This seems to come from resources/sw.js. It caches cross-origin GET requests, so requests to another localhost port get cached too. cache: 'no-store' doesn't help because the service worker handles the request before the browser's HTTP cache. There's also a second issue: initialization-script.js sends the caching config to the shared service worker whenever a window loads. Opening another widget can therefore reset the caching config for existing windows. I also couldn't find the caching config (defaultDuration, rules, urlRegex) in settings-schema.json, so there's currently no documented way to e

Describe the problem/motivation Zebar appears to rely on a fixed localhost port (127.0.0.1:6124) for its internal local server / WebView loading flow. This can conflict with other resident applications that bind the same port. In my case, it conflicted with Shure MOTIV Mix / ShureDeviceManager, and Zebar showed a blank / white bar because its internal local endpoint was no longer owned by Zebar. Since background apps like this often start automatically at login and remain resident, users currently have no reliable way to avoid this kind of conflict. Describe the solution you'd like Please add a supported way to configure Zebar's localhost listen port. A setting, config field, environment variable, or CLI flag would all work. Keeping the current default port is fine, as long as users can override it when another application is already using that port. Alternatives considered Changing startup order can sometimes avoid the visible Zebar failure, but it does not remove the port conflict it

Describe the bug I’m not sure why, but when running Zebar on Windows 11, it frequently requests GPS access — almost once per second. It might be related to the weather component, but with such a high request frequency, could this cause excessive battery consumption? 不知道为什么，在windows11系统中 运行 zebar，会频繁请求GPS，几乎时每秒钟请求一次。 我猜或许是和天气信息组件有关，但如此高的请求频率，会不会很耗电？ Reproduction No response Stack trace or error logs (if applicable) Version number v3.2.0