hypr: disable blur on omarchy-bar to stop transparency flicker#6018
Open
defer wants to merge 113 commits into
Open
hypr: disable blur on omarchy-bar to stop transparency flicker#6018defer wants to merge 113 commits into
defer wants to merge 113 commits into
Conversation
This tree is the source for omarchy-settings to install into /etc (for paths Omarchy fully owns) or stage at /usr/share/omarchy/etc-overrides (for paths upstream packages own, which the post_install copies into place). Package-owned drop-ins (no upstream conflict): - etc/docker/daemon.json - etc/systemd/system/docker.service.d/no-block-boot.conf - etc/systemd/resolved.conf.d/20-docker-dns.conf - etc/systemd/resolved.conf.d/10-disable-multicast.conf - etc/systemd/system.conf.d/10-faster-shutdown.conf - etc/systemd/system/user@.service.d/10-faster-shutdown.conf (renamed from .../faster-shutdown.conf for consistency) - etc/systemd/logind.conf.d/10-ignore-power-button.conf (replaces the previous in-place sed-edit of logind.conf) - etc/gnupg/dirmngr.conf - etc/sysctl.d/99-omarchy-sysctl.conf (renamed from the 99-sysctl.conf appendage; a migration cleans up the old path on existing installs) - etc/sysctl.d/90-omarchy-file-watchers.conf - etc/modprobe.d/omarchy-usb-autosuspend.conf (renamed from disable-usb-autosuspend.conf) - etc/sudoers.d/omarchy-asdcontrol (renamed from asdcontrol; $USER -> %wheel for packaging) - etc/sudoers.d/omarchy-tzupdate - etc/sudoers.d/omarchy-passwd-tries (renamed from passwd-tries for namespacing) Etc-overrides (upstream-owned paths; staged by the PKGBUILD at /usr/share/omarchy/etc-overrides/ and cp'd in by post_install): - etc/security/faillock.conf (owned by pam) - etc/nsswitch.conf (owned by filesystem) - etc/cups/cups-browsed.conf (owned by cups-browsed) - etc/plymouth/plymouthd.conf (owned by plymouth) All sudoers files validate with visudo -cf. The install scripts that previously wrote these files are updated or removed in follow-up commits.
Each of these scripts only wrote a single /etc file (or copied
config/bashrc into the user home). The corresponding files now ship
from the omarchy-settings package — either directly into /etc (drop-ins
the package fully owns) or via the /usr/share/omarchy/etc-overrides
post_install dance (for upstream-owned paths).
Deleted:
- install/config/timezones.sh -> etc/sudoers.d/omarchy-tzupdate
- install/config/sudoless-asdcontrol.sh -> etc/sudoers.d/omarchy-asdcontrol
($USER rewritten to %wheel)
- install/config/increase-sudo-tries.sh -> etc/sudoers.d/omarchy-passwd-tries
(faillock.conf side now in etc-overrides)
- install/config/hardware/ignore-power-button.sh
-> etc/systemd/logind.conf.d/10-ignore-power-button.conf
(replaces sed-edit of logind.conf)
- install/config/hardware/usb-autosuspend.sh
-> etc/modprobe.d/omarchy-usb-autosuspend.conf
- install/config/ssh-flakiness.sh -> etc/sysctl.d/99-omarchy-sysctl.conf
- install/config/config.sh -> /etc/skel seeds ~/.config from config/**;
~/.bashrc seeded from etc-overrides
- install/login/plymouth.sh -> theme files already shipped by
omarchy-settings; etc/plymouth/plymouthd.conf
handled via etc-overrides
A separate migration tidies up the old paths on existing installs.
all.sh entries updated to drop these scripts.
The three Docker config files (etc/docker/daemon.json, etc/systemd/system/docker.service.d/no-block-boot.conf, etc/systemd/resolved.conf.d/20-docker-dns.conf) now ship via the omarchy-settings package. The script keeps only the actions a static file can't do: - restart systemd-resolved so the new drop-in takes effect - usermod -aG docker $USER (user-specific, can't be packaged) - systemctl enable docker.socket and daemon-reload
…imit to runtime-only ops Each script's static-file write moves to omarchy-settings. The scripts keep only the runtime side: reload systemd, restart dirmngr, sysctl --system, or (for lockout-limit) the PAM seds that have to stay scripted because /etc/pam.d/system-auth and /etc/pam.d/sddm-autologin are upstream-owned and need targeted line edits rather than a full-file override. faillock.conf's deny=10 (formerly inside increase-sudo-tries.sh sed) now rides through the etc-overrides dance in omarchy-settings.
The three /etc writes (resolved.conf.d drop-in, nsswitch.conf override, cups-browsed.conf override) now ship via omarchy-settings. The service enables stay scripted because they need chrootable_systemctl_enable to work both inside the ISO chroot and on a live system.
config/mimeapps.list ships at /etc/skel/.config/mimeapps.list (via omarchy-settings's existing config/** -> /etc/skel/.config copy). New users get the full Omarchy MIME defaults on first login without running install scripts. install/config/mimetypes.sh shrinks to two runtime ops that a static file can't replace: - omarchy-refresh-applications: copies .desktop entries and icons into the user home and refreshes the desktop database - xdg-settings set default-web-browser chromium.desktop: sets the system-default browser; omarchy-install-browser overrides this if the user later picks a different browser.
Existing users upgrading from script-installed Omarchy still have files
the install scripts wrote at the OLD paths. The new package can't own
those old paths (they were either renamed or replaced by drop-ins), so
this migration tidies them up:
- /etc/sysctl.d/99-sysctl.conf: strip the appended net.ipv4.tcp_mtu_probing
line (new file is /etc/sysctl.d/99-omarchy-sysctl.conf)
- /etc/modprobe.d/disable-usb-autosuspend.conf: removed
(new file is /etc/modprobe.d/omarchy-usb-autosuspend.conf)
- /etc/sudoers.d/{passwd-tries,asdcontrol}: removed
(new files are /etc/sudoers.d/omarchy-{passwd-tries,asdcontrol})
- /etc/systemd/system/user@.service.d/faster-shutdown.conf: removed
(new file is 10-faster-shutdown.conf)
- /etc/systemd/logind.conf HandlePowerKey=ignore line: reset to its
commented default so the logind.conf.d/ drop-in is the only source
After cleanup, systemctl daemon-reload + sysctl --system to pick up the
new state immediately.
… idempotency Four corrections to the omarchy-settings transition: - bin/omarchy-update-system-pkgs: pass --overwrite for the 13 paths omarchy-settings now owns. Existing Omarchy installs would otherwise fail pacman conflict checks on the upgrade that ships the package (the files exist as unowned filesystem entries from the previous install scripts). The flags are no-ops once the transition release is everyone's baseline; remove then. - config/mimeapps.list: drop the HEY.desktop mailto mapping. HEY.desktop is generated by install/packaging/webapps.sh at install time, not shipped under applications/, so it isn't valid for a fresh /etc/skel user before the installer runs. - install/config/mimetypes.sh: add 'xdg-mime default HEY.desktop x-scheme-handler/mailto' as a runtime op since the mapping no longer lives in mimeapps.list. - install/config/increase-lockout-limit.sh: delete existing pam_faillock.so authsucc lines before re-adding, so re-running the installer doesn't duplicate the authsucc entry in /etc/pam.d/sddm-autologin.
…to package files Four scripts that wrote static /etc or /usr files become package-shipped files. The other config-script audit candidates (omarchy-ai-skill, nautilus-python, omarchy-toggles, input-group) correctly stay scripts — they're user-level operations, not /etc writes. New package-owned files (omarchy-installer/etc/, shipped by omarchy-settings): - etc/systemd/system/plocate-updatedb.service.d/ac-only.conf - etc/udev/rules.d/99-omarchy-power-profile.rules - etc/udev/rules.d/99-omarchy-wifi-powersave.rules The two udev rule files are renamed for namespacing (99-power-profile -> 99-omarchy-power-profile; 99-wifi-powersave -> 99-omarchy-wifi-powersave) and rewritten to invoke /usr/bin/omarchy-powerprofiles-set and /usr/bin/omarchy-wifi-powersave instead of $HOME/.local/share/omarchy/bin/... (both binaries ship in the omarchy package at /usr/bin/). The battery-present gate from the original scripts is dropped — the rules trigger on power_supply udev events, which are benign on desktops without batteries. (The runtime commands no-op on AC-only systems.) Script changes: - install/config/plocate-ac-only.sh: DELETED (file ships, daemon-reload happens via pacman hook). - install/config/unmount-fuse.sh: DELETED (file ships at /usr/lib/systemd/system-sleep/unmount-fuse via omarchy-settings). - install/config/powerprofilesctl-rules.sh: SHRINK to runtime ops (enable power-profiles-daemon, udevadm reload+trigger). - install/config/wifi-powersave-rules.sh: SHRINK to udevadm reload+trigger. - install/config/all.sh: drop the two deleted entries. bin/omarchy-update-system-pkgs: add --overwrite for plocate-updatedb drop-in and unmount-fuse paths (the udev rule renames need no overwrite since the new paths are virgin). migrations/1779307845.sh: remove the legacy 99-power-profile.rules and 99-wifi-powersave.rules paths on existing installs, then reload udev.
…potent legacy cleanup
- bin/omarchy-wifi-powersave: shopt -s nullglob. Previously, machines
with no wireless interfaces ran the loop once with the literal glob
('iface=*'), failed iw, and exited 237. With the new always-installed
udev rule that invokes this on every AC transition, the failure
would surface as failed transient omarchy-wifi-powersave-* units on
desktops. Now it cleanly no-ops.
- migrations/1779307845.sh: add 'systemctl daemon-reload' so the
plocate-updatedb.service.d/ac-only.conf drop-in is picked up on
upgrade. Arch's systemd pacman hook only triggers on
/usr/lib/systemd/system/*, not /etc/systemd/system/*.
- install/config/powerprofilesctl-rules.sh and wifi-powersave-rules.sh:
rm -f the pre-rename legacy paths before udevadm reload, so the
cleanup is idempotent outside the one-shot migration (matters for
re-install/downgrade testing).
The previous setup scattered systemctl enables across docker.sh,
printer.sh, bluetooth.sh, network.sh, powerprofilesctl-rules.sh, and
kernel-modules-hook.sh. Some used chrootable_systemctl_enable; others
used bare 'sudo systemctl enable'. Centralizing makes the install-time
service surface auditable in one place and consistent in chroot/non-chroot
behavior.
install/config/enable-services.sh enables:
- bluetooth.service
- cups.service, cups-browsed.service, avahi-daemon.service
- docker.socket
- iwd.service
- linux-modules-cleanup.service
- power-profiles-daemon.service
Each via chrootable_systemctl_enable, which uses 'enable --now' on a live
system and bare 'enable' in chroot (set OMARCHY_CHROOT_INSTALL=1).
Stays in original script (deliberately):
- sddm.sh: bare 'systemctl enable sddm.service' (no --now during install
would log the user out; lives in install/login/)
- limine-snapper.sh: limine-snapper-sync (bootloader-specific path)
- first-run/firewall.sh: ufw (deferred to first-run for UX)
- hardware/{t2,intel/lpmd,intel/thermald,apple/fix-suspend-nvme}: gated
on hardware detection
Side cleanups:
- install/config/kernel-modules-hook.sh: DELETED (sole line was the enable
for linux-modules-cleanup, now in enable-services.sh).
- install/config/hardware/printer.sh: DELETED (sole purpose was the
three cups/avahi enables; nothing else to do).
- install/config/hardware/network.sh: keep the systemd-networkd-wait-online
disable+mask; drop the iwd enable.
- install/config/hardware/bluetooth.sh: keep the AutoEnable=false sed and
the wireplumber/bt-agent user-session setup; drop the system enable.
- install/config/docker.sh: drop the docker.socket enable.
- install/config/powerprofilesctl-rules.sh: drop the
power-profiles-daemon enable.
- install/config/all.sh: register enable-services.sh; remove the two
deleted entries.
The package-installed paths live at /usr/share/omarchy; the script-install
paths live at ~/.local/share/omarchy. $OMARCHY_PATH is set by install.sh
during the install flow and by /etc/profile.d/omarchy.sh in package mode.
Scripts that hard-code the script-install path don't honour that and will
misbehave once shipped to /usr/bin.
16 files migrated via sed s|~/\.local/share/omarchy|$OMARCHY_PATH|g
and s|$HOME/\.local/share/omarchy|$OMARCHY_PATH|g:
bin/:
- omarchy-plymouth-{preview,reset,set}
- omarchy-refresh-{limine,plymouth}
- omarchy-reinstall-configs
- omarchy-show-logo
- omarchy-games-retro-install
- omarchy-install-gaming-battlenet
install/:
- config/branding.sh
- packaging/{fonts,icons}.sh
- post-install/{finished,pacman}.sh
- preflight/{migrations,pacman}.sh
Deliberately NOT migrated:
- bin/omarchy-dev-add-migration: uses 'cd ~/.local/share/omarchy' to
resolve a git repo for 'git log'. The packaged binary doesn't have a
git repo to read; this command only makes sense in dev mode where
the home path is the right one.
- bin/omarchy-install-browser:69: writes a string into a chromium
config file that chromium itself interprets; not a bash-resolved path.
- install/helpers/errors.sh:125: the boot.sh-style relaunch behaviour
needs a separate redesign.
Missed in the previous pass:
- bin/omarchy-launch-screensaver: alacritty/ghostty config paths
- bin/omarchy-refresh-applications: source paths for icons and .desktop
- bin/omarchy-refresh-config: docstring/comment references
Still NOT touched (intentional):
- bin/omarchy-reinstall-git: stages '~/.local/share/omarchy-{old,new}' for
the script-mode upgrade dance; needs redesign for package mode.
- bin/omarchy-dev-add-migration: uses 'cd ~/.local/share/omarchy' to read
a git log; only meaningful in dev mode.
- bin/omarchy-install-browser:69: writes a string into a chromium config file.
- install/helpers/errors.sh:125: boot.sh relaunch (separate redesign).
For shells outside the install flow (login shells, cron jobs, dev work) the install.sh-set OMARCHY_PATH isn't in scope. Without a system-wide default, omarchy-* commands shipped at /usr/bin can't find runtime data under /usr/share/omarchy/. profile.d sets OMARCHY_PATH=/usr/share/omarchy if not already set, so install.sh's override (to $HOME/.local/share/omarchy during script-install) still wins. The omarchy-dev-link workflow manages a symlink at /usr/share/omarchy that points at a local checkout when active. Also prepends $OMARCHY_PATH/bin to PATH if the directory exists (mainly matters for script-install mode; /usr/bin is on PATH for package mode).
The /etc/profile.d/omarchy.sh default for OMARCHY_PATH was being clobbered
by shipped config files that re-export the variable to the old script-mode
path. In package mode, every login shell, UWSM session, and Hyprland
autostart was effectively reversing the migration. Fix:
- default/bashrc: source from $OMARCHY_PATH/default/bash/rc; default
OMARCHY_PATH to /usr/share/omarchy if not set (so the source line
works in any boot order, including non-login interactive shells).
- default/bash/envs: change 'export OMARCHY_PATH=$HOME/...' to
'export OMARCHY_PATH=${OMARCHY_PATH:-/usr/share/omarchy}' so the
profile.d default and install.sh script-mode override both win.
- config/uwsm/env: same defaulting pattern. UWSM may not source
profile.d, so the inline default still matters.
- default/hypr/autostart.lua: quickshell launched from $OMARCHY_PATH/shell
(not literal $HOME path). The bash that runs hl.exec_cmd sees
OMARCHY_PATH propagated from UWSM env.
- config/chromium-flags.conf: --load-extension hard-codes
/usr/share/omarchy/... because chromium doesn't expand env vars or
'~'. The omarchy-dev-link workflow symlinks /usr/share/omarchy to a
checkout.
- bin/omarchy-install-browser: same chromium-flag path correction for
brave-origin-beta-flags.conf.
…during install The previous centralization into enable-services.sh accidentally changed semantics for three services: docker.socket, iwd.service, and power-profiles-daemon.service used to be enabled with bare 'sudo systemctl enable' (no --now); chrootable_systemctl_enable promoted them to 'enable --now' outside chroot. For iwd this is the riskiest: it's typically what's keeping the installer online, so starting it mid-install is at best a no-op and at worst can disrupt the active network connection. For docker.socket and power-profiles-daemon the change is cosmetic (the socket is already inactive, the daemon does no harm to start) but the original intent was deferral to first boot. New helper in install/helpers/chroot.sh: chrootable_systemctl_enable_only <unit> # plain enable, no --now enable-services.sh uses it for the three services that were previously bare-enabled. The other five (bluetooth, cups, cups-browsed, avahi-daemon, linux-modules-cleanup) keep the --now behavior they had under chrootable_systemctl_enable.
The previous comment said 'mainly relevant for the script-install path', but install.sh and default/bash/envs already prepend it there. The real reason is dev-link: when /usr/share/omarchy is a symlink to a local checkout, this prepend lets the checkout's bin/ override the /usr/bin/ copies installed by the package.
Sets up the shadow-dir pattern that omarchy-dev-link will use: when /usr/share/omarchy-dev exists (as a symlink to a local checkout), $OMARCHY_PATH resolves there instead of /usr/share/omarchy. The PATH prepend then makes the checkout's bin/ override the package's /usr/bin copies. This covers every hot-edit surface that resolves via $OMARCHY_PATH: bin/, default/, shell/, and themes/. Things that don't go through $OMARCHY_PATH (udev rules, systemd drop-ins, /etc-installed configs, plymouth themes, /etc/skel seeds) remain unaffected by dev-link and require omarchy-dev-pkg-test to verify changes — which is also what you'd want before shipping any of those anyway.
omarchy-dev-link (lands in a follow-up) writes OMARCHY_PATH=<checkout>
to /etc/omarchy.conf. Three boot/session entry points now source it
before falling back to /usr/share/omarchy:
- /etc/profile.d/omarchy.sh (login shells, SSH)
- config/uwsm/env (Hyprland session via UWSM)
- default/bash/envs (non-login interactive bash; duplicated for
SSH and similar)
All three use 'export OMARCHY_PATH="${OMARCHY_PATH:-/usr/share/omarchy}"'
so /etc/omarchy.conf wins over the default, and install.sh's script-mode
export wins over /etc/omarchy.conf (because both use the :- guard).
Hyprland updates session env on the fly via hyprctl setenv +
systemctl --user import-environment, so omarchy-dev-link can re-trigger
those to make live sessions pick up the new path without restart.
Lua's require() caches modules in package.loaded; without explicit invalidation, changes to default/hypr/*.lua or ~/.config/hypr/*.lua won't take effect after hyprctl reload even though hyprland.lua itself re-runs. The clear runs unconditionally — benefits both dev-link workflows (checkout files re-evaluate after every reload) and normal users who edit their own ~/.config/hypr/*.lua and run omarchy-restart-hyprctl. Cost is negligible: package.loaded has a handful of entries. Pattern matches the require_all.lua reload option (which sets package.loaded[module] = nil before require()), but applied broadly to the omarchy module namespace at the entry point so individual modules don't need to opt in.
The four dev-tools commands that complete the developer-ergonomics story for the package refactor: - omarchy-dev-link <path>: writes /etc/omarchy.conf so OMARCHY_PATH resolves to <path> in all new shells, the Hyprland session env, and systemd --user. Updates the live session via hyprctl setenv + systemctl --user import-environment, restarts omarchy-shell, and reloads Hyprland so the changes are visible immediately. Affects every tree resolved via $OMARCHY_PATH: bin/, default/, shell/, themes/, applications/, config/. - omarchy-dev-unlink: removes /etc/omarchy.conf and reverses the live session updates back to /usr/share/omarchy. - omarchy-dev-status: reports current dev-link state (configured path, current shell, hyprland session env). - omarchy-dev-pkg-test [pkg] [checkout]: builds and installs a package from the checkout via OMARCHY_SRC + makepkg -si --skipchecksums. Used for changes that land at fixed system paths (/etc/, /usr/lib/, udev rule bodies, plymouth themes, /etc/skel) that dev-link can't shadow. The built package's pkgver is tagged 'dev.<short-sha>[.dirty]' so 'pacman -Q' makes its source obvious. Defaults: package omarchy-settings, checkout ~/Work/omarchy/omarchy-installer, PKGBUILDs read from ~/Work/omarchy/omarchy-pkgs/pkgbuilds/. All four ship via omarchy-dev-tools (existing PKGBUILD wildcard). Verified package build picks them up at /usr/bin/omarchy-dev-*.
When the script is run under outer sudo, the environment loses HYPRLAND_INSTANCE_SIGNATURE, XDG_RUNTIME_DIR, and DBUS_SESSION_BUS_ADDRESS, so the 'hyprctl version' check silently fails and the live-session refresh (setenv / import-environment / restart shell / hyprctl reload) gets skipped. The user is left with /etc/omarchy.conf written but no session updates — confusing because the env in the current shell still shows the old value. Reject EUID=0 invocations with a clear message pointing at the right pattern: invoke as your user, the script prompts for sudo only when it needs to write /etc/omarchy.conf.
…nk-aware paths.lua
Two related fixes for omarchy-dev-link to actually affect Hyprland keybinds:
default/hypr/paths.lua: prefer /etc/omarchy.conf over the process env.
hyprctl setenv updates Hyprland's process env, but the user-reported case
shows it doesn't reach bind-exec dispatchers because their env is
captured at config-load time. Reading the dev-link conf directly means
paths.omarchy_path is correct on every hyprctl reload regardless of
whether the launching Hyprland session re-read its env.
default/hypr/envs.lua: explicitly hl.env("OMARCHY_PATH", ...) and
hl.env("PATH", "$OMARCHY_PATH/bin:$PATH") so keybind dispatchers (and
everything else spawned by Hyprland) inherit the dev-link values. PATH
is built with a dedup pass so reloads don't accumulate the bin/ prefix.
Tested locally: paths.lua reads /etc/omarchy.conf correctly; lua syntax
of both files validates with luac -p.
The previous format wrote 'export OMARCHY_PATH="${OMARCHY_PATH:-<path>}"'
to /etc/omarchy.conf, intended so install.sh's script-mode OMARCHY_PATH
could win over the dev-link value. But install.sh doesn't source
/etc/omarchy.conf (only profile.d/uwsm/bash do, all post-install), so the
guard was protecting a non-scenario.
It also caused a real bug: paths.lua parses /etc/omarchy.conf as text
and returned the literal '${OMARCHY_PATH:-<path>}' string as the
omarchy_path, breaking dev-link in Hyprland.
Switch to plain 'export OMARCHY_PATH="<path>"'. dev-link is the only
writer, and when it's active, its value should win unconditionally.
…uth to transition overwrites Two related fixes for installing package builds onto a system that has the legacy script-installed Omarchy files already in place: bin/omarchy-dev-pkg-test: split makepkg -s (build) from sudo pacman -U (install) so we can pass --overwrite='*' to pacman. makepkg -i forwards a fixed flag set to pacman and doesn't expose --overwrite, so dev pkg tests on an existing script-install fail on every conflicting file (plymouth themes, /etc drop-ins, sudoers). --overwrite='*' is correct for the dev use case: the build IS the new authoritative state. bin/omarchy-update-system-pkgs: add /usr/share/plymouth/themes/omarchy/* to the transition --overwrite list. The old install/login/plymouth.sh cp -r'd the theme files into that directory, so existing installs conflict on the omarchy-settings package's plymouth payload.
Mirrors the upstream tightening in install/config/timezones.sh (which this etc-overrides file replaced): scope the wheel passwordless rule to 'timedatectl set-timezone *' instead of the whole timedatectl, so the rule can't be used to flip other system clock settings. Adopted while rebasing onto current origin/omarchy-shell.
A pass over the install scripts, dev-tools commands, and Hyprland Lua files that I had stuffed with explain-everything preambles. Most of those rationales (which files ship where, why hyprctl setenv doesn't suffice, etc.) belong in commit messages or PR descriptions, not in code people have to read forever. Kept the few comments that document genuinely non-obvious behaviour: the keybind-env reason for hl.env in envs.lua, why the runtime PAM seds stay scripted in increase-lockout-limit, the chroot/--now distinction in chroot.sh, and the dev-pkg-test split-install reason.
Sequential 'dev-link A' then 'dev-link B' previously left A/bin in PATH because the prepend didn't strip the old one. unlink had the same issue (it was trying to strip $(dirname $0), which only worked if you invoked unlink via an absolute path that happened to match the dev-link bin). Both now read the previous OMARCHY_PATH from /etc/omarchy.conf before overwriting/deleting it, and strip that path's bin/ from PATH before prepending the new one (or nothing, for unlink).
Three modes the installer now branches on:
iso-chroot Running inside the new system's chroot from the ISO build.
pacman is configured by archinstall; systemd isn't running,
so service enables skip --now.
online-package Running on an existing Arch where the omarchy-* packages
are already installed. Skip base.sh and the bootstrap
preflight steps; only the per-host runtime ops in
config/login/post-install need to run.
online-git boot.sh path: clone into $HOME/.local/share/omarchy and
bootstrap everything from scratch.
install.sh derives OMARCHY_PATH from its own location, so the same script
works whether it's at /usr/share/omarchy/install.sh (package mode) or
$HOME/.local/share/omarchy/install.sh (git mode). install_mode_is helper
replaces direct ${OMARCHY_CHROOT_INSTALL:-} / ${OMARCHY_ONLINE_INSTALL:-}
checks in chroot.sh, finished.sh, errors.sh, mise-work.sh, preflight/pacman.sh.
Legacy vars still work through export_legacy_mode_flags, which sets
OMARCHY_CHROOT_INSTALL=1 / OMARCHY_ONLINE_INSTALL=true based on the
canonical mode for any caller that hasn't been updated.
bin/omarchy-install-mode prints the current mode for scripts/users that
need to introspect.
Smoke-tested all four entry paths (explicit mode, both legacy shims,
auto-detection from OMARCHY_PATH); each resolves correctly and the
legacy flags are exported in matching modes.
- install.sh: use realpath to follow symlinks when deriving OMARCHY_PATH from script location. Logical pwd left dev-link symlink chains pointing at the wrong dir; realpath resolves to the underlying checkout. - install/helpers/mode.sh: validate explicit OMARCHY_INSTALL_MODE values and exit on typos. Also export_legacy_mode_flags now UNSETS the contradictory legacy flag for each mode so unmigrated callers can't see both OMARCHY_CHROOT_INSTALL=1 and OMARCHY_ONLINE_INSTALL=true. - install/helpers/errors.sh: retry uses "$OMARCHY_PATH/install.sh" and preserves OMARCHY_INSTALL_MODE explicitly; the previous hardcoded ~/.local/share/omarchy/install.sh broke package-mode retries. - bin/omarchy-install-mode: soften the summary; the helper only knows the current env, not any persisted post-install state.
Introduce a self-contained omarchy-upgrade-to-4 command for legacy installs and remove the 4.0 package-layout transition from the normal migration runner.
Reorganizes Omarchy 4 around three layers for populating $HOME:
Seed: omarchy-settings ships defaults to /etc/skel; useradd -m
copies them on user creation
Finalize: omarchy-finalize-user (renamed from omarchy-setup-user)
handles only the runtime tweaks /etc/skel can't do — skill
symlinks, xdg-user-dirs, default browser/mailto, vconsole→hypr
keyboard sync, and install/user/all.sh
Resync: omarchy-reinstall-configs is the explicit, destructive
resync of /etc/skel into an existing user's $HOME
Package-owned files move out of config/ into default/, where the
omarchy-settings PKGBUILD installs them to real system paths:
config/environment.d/fcitx.conf -> /usr/lib/environment.d/
config/fontconfig/fonts.conf -> /usr/share/fontconfig/conf.avail/
config/mimeapps.list -> /usr/share/applications/
config/omarchy.ttf -> /usr/share/fonts/omarchy/
config/systemd/user/*.service -> /usr/lib/systemd/user/
config/uwsm/default -> /usr/share/omarchy/default/uwsm/
config/uwsm/env -> /usr/share/uwsm/env.d/10-omarchy
config/xdg-terminals.list -> /usr/share/xdg-terminal-exec/
omarchy-upgrade-to-4 grows a 'retire' action (renamed from 'move' to
clarify nothing is copied — the system path is owned by the new package
once the user's hash-matched ~/.config copy is removed). Mismatched
copies are kept as backups so user overrides survive the upgrade.
Other simplifications:
- Single env bootstrap at default/bash/env-bootstrap sourced by
/etc/profile.d/omarchy.sh, /etc/skel/.bashrc,
/usr/share/uwsm/env.d/10-omarchy, and default/bash/envs. PATH
prepend only in dev-link mode (production uses /usr/bin/omarchy-*).
- omarchy-refresh-config reads from /etc/skel/.config so refresh
means 'snap to skel'.
- omarchy-reinstall-configs collapses to 'cp -af /etc/skel/. ~/'
plus limine/plymouth/nvim refresh.
- omarchy-font-set uses awk against our own 30-omarchy.conf instead
of xmlstarlet; xmlstarlet dropped from omarchy-base.packages.
- Defer user systemd enables (bt-agent, sleep-lock,
recover-internal-monitor) to first-run via
install/user/first-run/enable-user-units.sh; delete
omarchy-user-systemctl-enable and the per-hardware install
scripts that called it.
- Wireplumber bluetooth-a2dp-autoconnect.conf moves to config/ so
/etc/skel ships it; install/user/hardware/bluetooth.sh deleted.
- Default terminal switched to foot.desktop.
- docs/file-layout.md documents the three-layer model and the
build-time repo→path map.
- Add default/bash/env-bootstrap to the build-time map and a dedicated section describing what it sets, who sources it, and the dev-link gate on the PATH prepend. - Drop 'bluetooth' from the install/user/all.sh hardware-quirks list (the per-hardware install script is gone now that the wireplumber config ships through /etc/skel and bt-agent enables at first-run). - Add a first-run section listing the post-login steps, including the new enable-user-units.sh that defers user systemctl enables.
Brings the omarchy-shell UI work (bar config panel, omarchy-config-shell-bar
CLI, tray dropbox/tailscale panels, model-usage plugin, transparent bar
contrast handling, etc.) onto the package architecture work from omarchy-4.
Conflict resolutions:
AGENTS.md
Take origin/omarchy-shell's heading rename (Setup Scripts -> Install
Scripts) and its new Privileged Commands section above it.
test/shell.d/config-test.sh
Keep both omarchy-4's package_defaults Python check AND
origin/omarchy-shell's omarchy-config-shell-bar shell tests. Drop the
one origin/omarchy-shell block that depends on
migrations/1779627463.sh — omarchy-4 deliberately empties the
migrations directory (pre-4 migrations fold into the upgrade bridge
in bin/omarchy-upgrade-to-4), and the existing
'4.0 upgrade is handled outside the migration runner' assertion
contradicts a 'migration exists' assertion.
Backup branch: omarchy-4-pre-omarchy-shell-merge-20260527170405
Reflects the two upstream changes in this work:
- omarchy-dev-tools folds into omarchy (bin/omarchy-dev-* ship with the
main package).
- omarchy-limine folds into omarchy-settings (limine + snapper configs,
mkinitcpio hooks, and the default/{limine,snapper}/ trees ship from
omarchy-settings; the package was always installed in lockstep with
it in the early bootstrap anyway).
Mental-model section: from four packages to two (omarchy +
omarchy-settings), plus the two unchanged independents (omarchy-keyring,
omarchy-nvim).
Build-time map: drop the omarchy-dev-tools and omarchy-limine columns;
add the new limine source files (omarchy_hooks.conf,
thunderbolt_module.conf, omarchy-defaults.conf, omarchy-uki.conf) under
omarchy-settings.
systemctl --user enable only writes the .wants symlinks; the services don't actually run until next login. Switching to --now enables AND starts them, so the first session has bt-agent (bluetooth pairing) and omarchy-sleep-lock active immediately rather than waiting a reboot. omarchy-recover-internal-monitor is Type=oneshot with a ConditionPathExists guard, so --now is harmless for it (it'll skip if the toggle isn't set).
omarchy-limine no longer exists as a separate package — it was folded into omarchy-settings (configs) and omarchy (bootloader stack hard dep). Listing it in install_omarchy_4_packages's pacman -Syu invocation produced 'error: target not found: omarchy-limine' on every run. Also fix the now-stale 'shipped by omarchy-settings / omarchy-limine' comment in the retire-action header (line 1119) — the files come from omarchy-settings alone now. The bootloader stack (limine, limine-mkinitcpio-hook, limine-snapper-sync, snapper) is hard-depended by the omarchy package, so dropping omarchy-limine from the explicit list doesn't change what gets installed on a real upgrade.
TEMPORARY: while the omarchy-4 stack is being iterated, the production edge/stable/rc channels at pkgs.omarchy.org/<ring>/x86_64 don't have the new omarchy and omarchy-settings packages — only omarchy-keyring and omarchy-nvim are published. The work-in-progress packages live in the dev repo at share.heyoodle.com/omarchy/dev/<arch> via omarchy-pkgs/bin/publish-dev-repo. To stop hand-editing pacman.conf after every run of this script, configure_pacman_channel() now emits a [omarchy-dev] block right above [omarchy] with SigLevel = Never and the share.heyoodle URL. Pacman honors repo declaration order, so dev packages take precedence when both ring publish them. The awk also dedupes any pre-existing [omarchy-dev] block (so rerunning the script doesn't pile up duplicate entries) and falls back to appending both blocks at the end if no [omarchy] section was present. Revert this block once the production rings have caught up.
Hyprland's global blur recomputes every time content behind a transparent layer shell is damaged. On terminal redraws (selection, cursor, scroll) this caused a one-frame fallback to the bar's solid background color.
Contributor
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Disables blur on the omarchy-bar layer to prevent a one-frame solid flash/flicker when content behind the transparent bar redraws.
Changes:
- Added a Hyprland layer rule to disable blur for the bar layer (
namespace = "omarchy-bar"). - Documented the rationale for the rule with an inline comment explaining the flicker mechanism.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hyprland's global blur recomputes every time content behind a transparent layer shell is damaged. On terminal redraws (selection, cursor, scroll) this caused a one-frame fallback to the bar's solid background color.