Double-tapping the year bar asks for a birth year and a life expectancy,
and a second bar appears below measuring one against the other. Tab moves
between the two, Enter commits the pair, Escape drops them. Hovering the
bar names the thing, and double-tapping it puts it away again.
A birth year rather than an age, so the bar keeps counting on its own
instead of going stale the moment it is entered. Expectancy defaults to
ninety and falls back to it when what is entered makes no sense, so the
bar always has something to measure against; a birth year that makes no
sense leaves the bar hidden instead, which is also where it starts.
Putting the bar away keeps the expectancy, so setting a birth year again
brings your own number back rather than the default.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A cloned bar widget is copied out on its own, so a relative JS import
lands in a directory without the file and the clone fails to load. Point
those imports back at the bundled module, the same way Qt.resolvedUrl()
references were already rewritten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claiming the shared suppression flag before showing meant the outgoing
panel's close cleared it again, leaving the incoming panel open with the
indicators still revealed. Guarding the clear instead only moved the
problem: handing off to a panel that does not manage the flag left it
stuck on, and the center indicators stopped revealing on hover for good.
Claim it after the handoff instead. The panel taking over always wins,
and a handoff to a panel that knows nothing about the flag still leaves
it cleared.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Clicking the clock reveals a month grid with ISO week numbers, a year
progress meter, and month stepping. Right click walks the common label
formats and writes the chosen one back to shell.json, so the bar shows
what the config stores. The week start toggles from the grid's "W"
heading and persists as weekStartDay, defaulting to the locale's own
first day.
Rich popup widgets live in their own plugin directories, so the clock
moves out of bar/widgets/ into panels/clock/. The id is unchanged, so
existing layouts and centerAnchor keep working.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The bar identifies a panel by the widget mounted in its slot, but the
nested panel handed the popout coordinator itself. The open-panel mark
never lit under the weather pill, and Tab could not leave the panel.
Closing for a popout switch also cleared the shared hover-reveal flag the
incoming panel had just set.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A center-anchored module is mounted twice: the copy that is drawn, and a
zero-size placeholder holding its place in the flow beside the anchor.
findPanelWidget returned whichever registered first, and that order is
not stable across a live bar reconfiguration, so a panel could open
anchored to the invisible copy -- mispositioned, with the drawn slot
never lighting up and switchPanelFrom unable to find it again.
The mark was also always 55% of the slot, which fits an icon but
underlines only a fraction of a text label, and runs the full height of a
multi-line module on a vertical bar. Modules can now say how long the
mark should be along the bar; anything that does not answer keeps the old
proportion.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The center layout was reordered when the indicators moved next to the
clock, but the assertion kept the old order, so this has been failing on
quattro since.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
zram-size = min(ram, 8192) is Fedora's default since F34, where
zram-fraction=1.0 with max-zram-size=8192 has run on desktops for five
years. The previous min(ram / 2, 8192) halved that on every machine
below 16G with nothing behind the fraction; at 16G and above the two
already agree.
A changed size only reaches a running device on the next boot, so the
migration resizes an empty device now and asks for a reboot otherwise.
It asks the generator what the config evaluates to rather than
repeating the expression here, and does neither when the device already
matches.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
libfprint-git only existed to carry the focaltech_moc driver and the
FocalTech FT9349 (2808:a97a) ID ahead of a release. libfprint 1.94.100
has both and is in the Arch repos, so fingerprint setup installs stock
libfprint again and a migration swaps existing installs back.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
pacman checks file conflicts during transaction prepare, so the --overwrite
entry added alongside /etc/systemd/zram-generator.conf never got to run: the
copy of omarchy-update-system-pkgs driving the upgrade is the one already on
disk. Every machine carrying archinstall's copy aborted the transaction.
zram-generator.conf(5) reserves /etc for the local admin and has vendors ship
snippets under /usr/lib/systemd/zram-generator.conf.d/, where drop-ins outrank
the main config file. Nothing collides, and the tuning wins whether or not
archinstall's file is still around.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LjeyQZsNBxqyYy9z8KaKm7
A Dell XPS 14 with no fingerprint reader was invited to set one up on first
run. Its Synaptics webcam bridge, 06cb:0701 "SVP7500" bound to usbio-bridge,
matched omarchy-hw-fingerprint on the bare 06cb vendor ID.
The vendor list already excludes Elan and STMicro for being multi-purpose, but
Synaptics is just as multi-purpose and was left in. Dropping 06cb is not an
option: Synaptics and Validity are among the most common real reader vendors,
and many of those readers report no product string at all, so the vendor ID is
the only signal that finds them.
The vendor guess is now qualified instead. libfprint drives every reader it
supports from userspace over libusb, so a real reader sits with no kernel
driver bound to any of its interfaces, while the bridges, touchpads and cameras
that share these vendor IDs all bind one. The guard applies only to the fuzzy
vendor-ID path; a device whose product descriptor names it a fingerprint reader
is still trusted outright, since that signal is precise enough on its own and
should not be lost to a driver that happened to claim the device.
The menu entry was a second surface for the same bug. Setup > Security >
Fingerprint carried no when clause, unlike the Remove entry beside it, so it
appeared on every machine and dead-ended in the setup script's own hardware
check. It now gates on the same detector.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017q97Rsk8KwgaPUVq5ArLgM
A fresh install on a Dell XPS 14 spent 73s in "Configuring system", and two
silent gaps in the install log account for 66s of it. Both are the same
redundant work.
hardware/all.sh ran ipu7-camera.sh before ptl-kernel.sh. intel-ipu7-camera
pulls in ipu7-drivers, vision-drivers and v4l2loopback, so DKMS compiled all
three against the stock linux kernel and built a UKI for it. ptl-kernel.sh
then installed linux-ptl, which recompiled the same three modules against the
new kernel, and its pacman -Rdd of linux followed with three dkms removes and
yet another UKI rebuild. The log shows four UKI builds where one would do, and
everything the first script produced was deleted 42 seconds after it was made.
Running the kernel swap first means the DKMS modules are only ever built
against the kernel the machine actually keeps, which returns roughly 25s.
ptl-kernel.sh still installs linux-ptl before removing linux, so one redundant
UKI build for the stock kernel remains. Removing first would save it but would
leave the machine with no kernel at all if the linux-ptl install failed, so the
safe order stays.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017q97Rsk8KwgaPUVq5ArLgM
Closing the lid could suspend the machine with the session still exposed.
omarchy-sleep-lock held a delay inhibitor and waited for Quickshell to report
the session secure, but a delay inhibitor is a timer rather than a promise:
logind suspends once InhibitDelayMaxSec expires, locked or not. The default is
five seconds, and closing the lid also reconfigures displays -- exactly when
the lock service is waiting for the screen set to settle before it can secure.
The race is now off the critical path. switch:on:Lid Switch runs
omarchy-system-lid-close, which requests the lock the moment the lid closes,
before logind has decided to suspend at all, so the inhibitor window usually
finds the session already secure. A docked lid close does not suspend
(HandleLidSwitchDocked defaults to ignore) and must not lock either, since that
is clamshell mode still in use on the external display, so the handler gates on
the same closed-and-undocked pair logind itself keys on.
Suspends that never touch the lid -- idle timeout, the system menu, low battery
-- still arrive through the inhibitor, so that path gets room to work too. The
shipped drop-in raises InhibitDelayMaxSec to 15s, and the helper derives its
budget from logind's live InhibitDelayMaxUSec rather than assuming the drop-in
landed: a machine that has not reloaded logind yet, or that carries its own
override, gets a budget that fits what logind will actually allow. It leaves
logind a fifth of its own window and caps at 12s, so a hand-raised window
cannot strand a closed laptop awake in a bag.
The wait itself had three defects. Its deadline arithmetic read EPOCHREALTIME
assuming a period, so under any comma-decimal locale the subtraction parsed as
bash's comma operator and silently voided the deadline, leaving only the
attempt counter to stop it. The lock request shared the status polls' timeout
and exited on first failure, so a shell 300ms slow meant suspending unlocked;
it now has its own budget and is simply retried, since asking again is
idempotent. And a refusal the shell reports on stdout with a zero exit --
missing-pam -- read as success, burning the whole window on a lock that could
never happen.
Every call is bounded by what is left of the budget rather than by an estimate
of what the step should cost, so the deadline holds on hardware slower than
anything the constants were fitted to.
Failure is still possible and it used to be silent. It now writes to the
journal and raises a critical notification, which lands on the screen the user
unlocks into.
Incidentally, monitor-recovery-test asserted lid probing against
omarchy-hw-clamshell after that logic moved to omarchy-hw-laptop-closed. It
aborted the file under set -e, skipping the nine assertions behind it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1781158082.sh matched an explicit list of three legacy spellings for
~/.config/nvim/lua/plugins/theme.lua. At least one more exists in the
wild -- "../../../../.config/omarchy/current/theme/neovim.lua" -- so
those installs fell through the case, kept a dangling link, and Neovim
loaded no colorscheme spec at all. The failure looks theme-specific
because it only surfaces when you next switch themes.
Editing that migration would not help anyone, since it is already marked
applied. Add a new one that matches the shared suffix instead of an
enumerated list, so every spelling of the pre-state-dir path is caught.
It exits early when the link already points at the state directory and
ignores targets outside omarchy/current, leaving custom links alone.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LjeyQZsNBxqyYy9z8KaKm7
Both slots held #026fde, so strings and numbers rendered in one color
and syntax highlighting lost the distinction entirely. It mattered less
when the theme shipped its own nvim and vscode files; now that both
generate from this palette, the collision is visible everywhere.
The green slot takes a violet. Lupine's hues sit at 210, 214, 224, 267
and 301, leaving one real gap between blue and magenta, and that gap is
the only place a new color fits without either crowding an existing hue
or breaking the blues-and-purples character. Its bright variant becomes
a lavender, which suits a theme named for the flower. Nothing here reads
as green; the slot keeps its ANSI name, not its usual hue.
Yellow, orange and cyan remain close to each other. Pulling those apart
means either warm hues or a wider spread than the theme allows, which is
a bigger change than this one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018CC9kSQv8ZEogaxDoeKBzL
The JPEG drew the wordmark in #358fff on pure white, matching neither
the accent nor the background. Every other theme's omarchy wallpaper is
a flat two-color image: the theme's background behind its accent. Lupine
now follows that, so the wallpaper, the lock screen, and the focused
window border are all one blue.
Recolored from the shared wordmark rather than redrawn, so the glyphs
land on the same pixels as every other theme. JPEG was the wrong
container for two flat colors anyway; at one bit per pixel the PNG is
2KB against 71KB, with no ringing around the letters.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018CC9kSQv8ZEogaxDoeKBzL
Drops city, lavender-bloom, dusk-horizon, purple-mountains, lake-dawn,
and snowy-dawn, then renumbers the survivors so the sequence stays
contiguous. The remaining set is uniformly pale, which is what a light
theme needs; the cut ones were mid-tone or saturated enough that the
bar and window borders lost contrast against them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018CC9kSQv8ZEogaxDoeKBzL
Rename the palette keys to the canonical background/foreground names the
resolver actually reads. The short bg/fg spellings were never aliased, so
every derived key was silently falling back.
Fill in the orange and brown slots too. Lupine is a deliberately cool,
near-monochrome blue palette, so both stay in family rather than
introducing warm hues the theme never had.
Drop neovim.lua and vscode.json. They pinned third-party extensions that
had to be installed separately; the generated templates cover both from
colors.toml alone.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018CC9kSQv8ZEogaxDoeKBzL
Convert the Lupine theme to the semantic color system introduced in the
quattro/Omarchy 4 line:
- Rewrite colors.toml from the old accent/foreground/background/color0-15
scheme to the semantic palette (mode, bg/fg ramp, named ANSI hues, and
bright_* variants). The chromatic palette is preserved exactly; only the
keys are renamed.
- Replace the empty light.mode marker with mode = "light".
- Drop the hand-shipped btop.theme and chromium.theme; both are now
generated from default/themed/*.tpl at theme-set time.
Selection now follows the convention used by the other light themes
(selection_foreground = bright_fg over a light selection background)
instead of the previous inverted dark selection bar.
Replaying an empty history did nothing at all on screen, which reads as
a dead keybinding rather than an empty log.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The reader is still reachable on an external keyboard or a docked
laptop, so hiding the icon and skipping the scan just forced the
password. sudo and polkit keep their pam_exec lid gates.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The user override was written with mode="assign", but it loads after the
package default has already assigned JetBrainsMono, so it never displaced
it. prepend_first puts the chosen family at the head of the list.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Tensaku shows a "Pick a default annotation size factor" dialog until
its persisted state names one. Neither config.toml nor the CLI flag
suppresses it, so ship the state file itself.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Solitude had no unlock assets at all, so it fell back to the default
Plymouth logo. Last Horizon shipped a preview-unlock.png derived from
Nord's that still carried Nord's navy #2e3440 entry-box fill; only the
background and logo had been recolored.
Both are now generated the way the rest of the set was: the logo mask
recolored to the theme's accent, and the preview rendered by the same
pipeline as `omarchy plymouth preview` using each theme's background
and foreground. Last Horizon's unlock.png was already correct and is
untouched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018CC9kSQv8ZEogaxDoeKBzL
It was the user override file for the first Quickshell bar, back when the
bar layered it over bar-defaults.json. Unifying everything into
shell.json left an empty file that installs and the quattro upgrade kept
faithfully copying around.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Moving them ahead of the clock left the old entry in place, so a fresh
config rendered the widget on both sides of the time.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
tmux only raises an activity flag for windows that are not currently
selected, so a long-running command in the window you left selected --
the common case, since you switch away by moving your Hyprland focus
elsewhere rather than by selecting another tmux window -- finished
silently and the indicator never lit.
Windows now also count as waiting when they are selected in an attached
client, every client showing them is unfocused, and their window_activity
is newer than an @omarchy_unfocused_activity watermark. The watermark is
stamped by a new `track` subcommand wired to client-focus-in/out and the
existing select-window hooks, so it records where attention last was.
The hooks pass #{window_id} and #{window_activity} as arguments, which
tmux expands when the hook fires; run-shell -b would otherwise let output
arriving during the handoff be swallowed by the new watermark. The focus
hooks take index 100 to leave a user's own bindings alone.
That state has no hook of its own, so it needs polling to be noticed.
The probe therefore moves out of the indicator and into a service plugin,
alongside nightlight and battery. A bar surface exists per monitor and
each one instantiates every indicator twice, once per block, so a timer
on the indicator meant a shell-out per instance per tick -- four probe
processes every three seconds on a two-monitor machine, forever. One
service polls for the whole shell instead.
Sharing the state also fixes what per-instance polling would have papered
over: each indicator used to own its own count, so a timer-driven update
only refreshed the bar it ran on and left the other monitors stale.
Refreshes still arrive over the existing indicator broadcast, which now
coalesces into a single run no matter how many bars relay it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018CC9kSQv8ZEogaxDoeKBzL
The lineup now reads toward the clock instead of away from it, so Stay
Awake sits nearest the time, then do-not-disturb, night light, reminder,
screen recording, dictation, and tmux alerts trailing off to the left.
Active indicators render after the hover-revealed ones so they stay
against the clock, and a newly active indicator joins on the far side
rather than shoving the ones already showing sideways.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The tmux alert hooks fire omarchy-shell through run-shell, and run-shell
builds its own environment rather than passing the server's along, so the
hook ran without WAYLAND_DISPLAY. qs matches instances by display, so every
refresh from a bell died at "omarchy-shell is not running", which -q then
swallowed by design.
That left the indicator with no way to turn itself on. Its five second poll
only runs while the indicator is already active, so an alert raised after
startup was invisible until the shell happened to restart with the window
still flagged. The icon appeared roughly never.
Recovering the display from the socket in XDG_RUNTIME_DIR fixes it in the
one place that needs it, and covers any other caller reaching the shell from
a stripped environment rather than just the tmux hooks.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Omarchy installed zram-generator but never shipped a config for it, so the
only zram tuning any machine had was whatever the ISO wrote once, and the VM
sysctls were untouched kernel defaults aimed at spinning disks.
The generator's own default caps the device at 4G, which on a large machine
sends reclaim to the hibernation swapfile far earlier than it needs to go.
Ship min(ram / 2, 8192) instead, matching what Fedora settles on, and state
the priority explicitly since it has to sit above the pri=0 that
omarchy-hibernation-setup gives the disk swapfile.
The four sysctls follow from swap being RAM rather than a disk. swappiness
above 100 says evicting an anonymous page beats dropping a page-cache page
that would have to be read back, which is true once swap is compressed
memory. page-cluster drops to one page per fault because the default of 8
buys readahead for a seek zram doesn't have and pays a decompression for
each page. Zeroing watermark_boost_factor stops fragmentation from producing
reclaim bursts while memory is still free, and raising watermark_scale_factor
gives kswapd room to reclaim in the background instead of letting allocations
stall in direct reclaim. The last two are what actually addresses the stutter
people notice and misread as swap being used too eagerly: proactive swapping
to zram is the cure, and synchronous direct reclaim is the disease.
Every ISO-installed machine already has an unowned zram-generator.conf, which
pacman would refuse to overwrite, so both upgrade paths need it listed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The apps list rebuilt its rows by writing into the maps held by the menu's
items and itemOrder var properties. Writing into an object owned by a QML var
property is not reliable: the same row object written into a plain JS object
always lands, but written through the property it occasionally arrives with the
key created and the value undefined. One write per rescan was lost, on a
different app each time.
A lost write left an id in itemOrder with no item behind it. The old purge only
deleted app rows it could find in items, so the orphan survived the next merge,
the add loop appended a second row for the same app, and the list grew by one --
permanently, and again on every later rescan. Touching a single desktop file
fires around a dozen merges, because the entry model emits valuesChanged per
insert and removal while it reconciles, so duplicates piled up quickly: nine
YouTube rows on the reporting machine, and Alacritty doubled before that.
The bookkeeping moves into MenuModel as two pure functions that build fresh maps
for the caller to assign in one shot, so the fragile write disappears. They also
make the merge self-healing rather than merely correct-when-nothing-is-lost: an
id with no item is dropped instead of carried forward, and an id is listed once
even when two desktop entries claim it -- so no single dropped write can compound
into a duplicate row again. The bash-backed providers behind the font and power
profile lists had the same latent bug and get the same treatment.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TJQJfHXXApUk6En8EZisHg
Clicking the Voxtype or fingerprint invitation did nothing. The launcher
execs setsid, which forks because the transient unit's main process is
already a process group leader, so the unit exits within milliseconds and
systemd's default control-group kill took the still-starting terminal down
with it. Run those units with KillMode=process instead.
The invitation tests had also drifted from the two-unit design and were
failing; teach the systemd-run mock to run the command it is given.
Both notifications are sent from background subshells, so whichever
notify-send registered first won the bottom slot. Give the update toast a
tick to register so Wi-Fi lands newest and stacks on top.
