* Show OSD and sync touchpad steps when scrolling bar widgets
Scrolling the volume or brightness icon in the bar changed the value
directly without ever calling omarchy-osd, so only the keyboard media
keys showed the popup. On top of that, a touchpad's stream of many
small wheel events per finger-drag wasn't matched to a mouse's single
±120 notch per click, so touchpad scrolling felt uncoordinated and
uneven next to the keyboard/mouse behavior.
- shell/plugins/panels/audio/Panel.qml: accumulate raw wheel delta and
only apply a step once it crosses a full mouse-notch's worth, so
touchpad and mouse move the volume in identical 5% increments, and
ping the OSD each time a step actually lands.
- shell/plugins/panels/monitor/Panel.qml: same accumulator for
brightness, with a 5% floor so scrolling down can never blank the
screen.
- shell/plugins/osd/Osd.qml: animate the progress bar's width instead
of snapping, so successive steps glide smoothly.
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Fix bar wheel OSD behavior
* Normalize scaled wheel events
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: David Heinemeier Hansson <david@hey.com>
SCALE only applies to the focused monitor, which is easy to lose track
of with several displays. Show the focused monitor's name on the right
of the SCALE header (matching the BRIGHTNESS/TEXT SIZE value
convention), hidden when only one display is enabled.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
A macOS-style slider snapping to curated stops (9-20px), applied via
omarchy-display-text-size. Suppresses hover-driven focus changes while a
size change reflows the panel, so h/l on the slider can't let a shifted
row steal keyboard focus.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Each `bash -lc` starts a login shell that re-sources the profile
(mise activation, /etc/profile.d) on every invocation — ~16 forks per
call versus ~2 for `bash -c` — which taxes every menu/panel/launcher
action the shell shells out for. The session already exports PATH and
env to the shell, so omarchy commands resolve fine under `bash -c`.
Switch the internal/omarchy-owned spawns (theme+background switches,
brightness, monitor scaling, DNS, lock/fingerprint, keyboard-layout
probe, voxtype status, and the `:`/printf state-file writes) to
`bash -c`. Leave `bash -lc` on the sites that run user-configurable
commands (custom bar-widget exec, menu provider/guard scripts,
launcher scan commands, configurable idle/screensaver command), where
a user's command may rely on their login environment.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The monitor panel polled `omarchy-monitor-state` every 5s (26 forks per
call) and the network panel polled `omarchy-network-status` every 3s,
both with `running: true` rather than gating like the sibling panels.
Monitor: gate the poll on `opened` (brightness/scale are only shown in
the open panel, which already refreshes on open) and drive the bar glyph
from Quickshell.screens instead of the polled display list, so monitor
count stays correct without polling.
Network: the bar pill needs live-ish state, so keep polling but at 10s
instead of 3s. (Deriving the pill from the native Networking service
would remove the poll entirely; left as a follow-up since it needs Wi-Fi
state testing.)
Idle fork rate drops ~20/s to ~14/s.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
