diff options
| -rw-r--r-- | todo.org | 30 |
1 files changed, 21 insertions, 9 deletions
@@ -32,11 +32,14 @@ Disabled 2026-06-12 (bind and cycle entry points removed; Super+Shift+S reassign The support machinery was deliberately kept for this task: =layout-navigate= and =layout-resize= retain their scrolling branches, =waybar-layout= still renders the scrolling state, and the unbound legacy =cycle-layout= script still lists it. Re-enabling is two lines: add =scrolling= back to =LAYOUTS= in =layout-cycle= and restore a direct-jump bind (the old chord is taken now — pick a new one). The =tests/layout-cycle= suite pins the disabled state and will go red on re-enable, which is the reminder to update it. -** TODO [#C] Waybar indicators unevenly spaced :quick:solo:waybar: +** DONE [#C] Waybar indicators unevenly spaced :quick:solo:waybar: +CLOSED: [2026-06-24 Wed] :PROPERTIES: -:LAST_REVIEWED: 2026-06-09 +:LAST_REVIEWED: 2026-06-24 :END: -The right-side module icons don't sit at even intervals — spacing reads as inconsistent across the group. Tune the per-module margin/padding in =dotfiles/hyprland/.config/waybar/style.css= so the icons are evenly distributed. Noticed 2026-05-21 after adding the airplane indicator. +The right-side module icons don't sit at even intervals — spacing reads as inconsistent across the group. Noticed 2026-05-21 after adding the airplane indicator. + +Done 2026-06-24: a screenshot showed the standalone module icons were already even — the unevenness was the tray, whose icons clustered tight (tray =spacing: 4= vs the ~0.3rem margins on every other module). Bumped tray =spacing= 4 → 10 in the waybar =config=; restarting waybar and re-screenshotting confirmed the row reads even. The lever was the tray spacing, not the per-module CSS the original body guessed at. ** TODO [#C] Wlogout exit-menu buttons are rectangular, not square :PROPERTIES: :LAST_REVIEWED: 2026-06-24 @@ -642,7 +645,10 @@ Identify attack vectors, what's mitigated, what remains :PROPERTIES: :LAST_REVIEWED: 2026-06-24 :END: -=archsetup:2403= installs =python-lyricsgenius= with =--mflags --skipinteg=, skipping makepkg integrity + PGP checks — a workaround for an expired-signature issue upstream (surfaced by the 2026-06-23 --noconfirm audit). Periodically test whether the upstream issue has cleared: if a plain =aur_install python-lyricsgenius= builds without complaint, drop the =--skipinteg= workaround. Removal needs a real AUR build to confirm, so it isn't a blind change. +archsetup installs =python-lyricsgenius= with =--mflags --skipinteg=, skipping makepkg integrity + PGP checks — a workaround originally for an expired-signature issue upstream (surfaced by the 2026-06-23 --noconfirm audit). Periodically test whether the cause has cleared: if a plain =aur_install python-lyricsgenius= builds without complaint, drop the =--skipinteg= workaround. Removal needs a real AUR build to confirm, so it isn't a blind change. + +*** 2026-06-24 Wed @ 17:55:34 -0400 Rechecked: still needed, but the cause changed +Ran =makepkg --verifysource= on the current AUR PKGBUILD (3.7.0-1). The package tarball =lyricsgenius-3.7.0.tar.gz= now passes its b2sum — the original expired-PGP-signature problem is gone (the PKGBUILD no longer carries any =validpgpkeys=). But integrity still FAILS, on a different file: =LICENSE.txt=, which the PKGBUILD fetches from the project's github master and pins a b2sum for. github master is a moving target, so that b2sum drifts and =--skipinteg= is still required. This is structural (not a transient upstream fix away), so it likely won't clear until the maintainer pins the LICENSE to a tagged release. Updated the archsetup comment to the real cause. Keep rechecking, but lower expectations of it clearing. ** TODO [#B] Test each modernization thoroughly before replacing :PROPERTIES: @@ -702,10 +708,12 @@ Priority C because snapshot-based testing meets current needs :END: Practical guidelines for working in public spaces -** TODO [#C] Install adopted modern CLI tools :tooling:solo: +** DONE [#C] Install adopted modern CLI tools :tooling:solo: +CLOSED: [2026-06-24 Wed] :PROPERTIES: :LAST_REVIEWED: 2026-06-24 :END: +Done 2026-06-24: added bat/dust/hyperfine/doggo to archsetup General Utilities (tealdeer was already declared), installed all five on velox, set =BAT_THEME=ansi= in =common/.profile.d/tools.sh= (tracks the dupre terminal palette), seeded the tldr cache. ratio still needs the =pacman -S= (additive; lands on its next archsetup run). Decision (Craig, 2026-06-24): adopt all five recommended tools — =bat=, =dust=, =hyperfine=, =tealdeer=, =doggo= (all in extra). Add them to archsetup's package list and install on both machines. Optional candidates (=xh=/=jless=/=sd=/=ouch=) declined for now. Full evaluation: [[file:docs/2026-06-10-modern-cli-tools-evaluation.org][docs/2026-06-10-modern-cli-tools-evaluation.org]]. - Add the five to the appropriate pacman package section in =archsetup=. @@ -730,11 +738,12 @@ Migration scope: CLOSED: [2026-06-24 Wed] Decision (Craig, 2026-06-24): keep nautilus only; skip yazi. File management lives in Emacs dired plus the Super+F dirvish popup, so a TUI file manager has no daily user here. ranger was already ruled out (frozen upstream). Full evaluation: [[file:docs/2026-06-10-file-manager-evaluation.org][docs/2026-06-10-file-manager-evaluation.org]]. Follow-on surfaced: nautilus needs dark theming (filed as its own task). -** TODO [#B] Theme nautilus to a dark theme :bug:solo: +** DONE [#B] Theme nautilus to a dark theme :bug:solo: +CLOSED: [2026-06-24 Wed] :PROPERTIES: :LAST_REVIEWED: 2026-06-24 :END: -nautilus renders blindingly white (Craig, 2026-06-24). It's a GTK4/libadwaita app, so it ignores the GTK theme name (Adwaita-dark) and instead follows the system color-scheme preference =org.gnome.desktop.interface color-scheme=. Likely fix: set =color-scheme = 'prefer-dark'= via the dconf block archsetup already writes (the GNOME-interface dconf settings added for the portal-gtk timeout), then apply it live (=gsettings set org.gnome.desktop.interface color-scheme prefer-dark=). Investigate whether the existing dconf db already sets this and why nautilus isn't picking it up. Apply on velox + ratio, add to archsetup so fresh installs get dark by default. Verify nautilus opens dark. +nautilus rendered blindingly white (Craig, 2026-06-24). As a GTK4/libadwaita app it ignores the GTK theme name and follows =org.gnome.desktop.interface color-scheme=. Root cause: velox had no system-wide dconf db at all — no =/etc/dconf/profile/user=, no =/etc/dconf/db/site.d/00-archsetup-defaults=, no compiled =site= db — so archsetup's declared default (=color-scheme='prefer-dark'=, already at =archsetup:1109-1119=) never reached the machine. velox predates that block. Fix (velox, live): created the profile + site defaults exactly as archsetup writes them and ran =dconf update=. =gsettings get= now returns =prefer-dark= / =Adwaita-dark=, and a restarted nautilus renders dark (screenshot-verified). No archsetup change needed — fresh installs already get this. ratio may have the same gap (couldn't check from velox) — see the Active Reminder. ** TODO [#C] Review current tool pain points annually :PROPERTIES: @@ -854,11 +863,14 @@ From the roam inbox (2026-06-22): replace the spread-out sysmonitor readouts (te ** TODO [#C] Proton Mail Bridge font size :chore: From the roam inbox (2026-06-22): adjust the Proton Mail Bridge UI font to a comfortable size. The bridge is a Qt app, so it likely keys off Qt scaling or the qt5ct/qt6ct config like the other Qt apps (QT_SCALE_FACTOR or a font setting). -** TODO [#C] Highlight current month and year in the calendar hover :feature:waybar:quick:solo: +** DONE [#C] Highlight current month and year in the calendar hover :feature:waybar:quick:solo: +CLOSED: [2026-06-24 Wed] :PROPERTIES: :LAST_REVIEWED: 2026-06-24 :END: -From the roam inbox (2026-06-24): the waybar clock's calendar tooltip highlights today's date in goldenrod; the current month and year header should be goldenrod too. Mirror the existing date-highlight pango/CSS span onto the calendar header (=format-calendar= / the clock module's tooltip format). Small mechanical tweak following the established highlight pattern; residual is a visual spot-check of the hover. +From the roam inbox (2026-06-24): the waybar clock's calendar tooltip highlights today's date in goldenrod; the current month and year header should be goldenrod too. + +Done 2026-06-24: the date module is the custom =waybar-date= script (not the built-in clock), so the highlight lives in its tooltip markup. Added a sed wrapping line 1 of the current-month =cal= output (the centered "Month Year") in the same =#daa520= goldenrod the day highlight uses. Verified the tooltip JSON carries =<span color='#daa520'><b>June 2026</b></span>= with today's highlight intact and waybar live; the on-hover look is Craig's spot-check. ** TODO [#C] Rename idle inhibitor to something more intuitive :chore:waybar: :PROPERTIES: |