v0.2.1

HelloUI

v0.2.1 (2026-07-27)

Full Changelog Previous Releases

• Release v0.2.1 with taint-safe frame fixes
  Keep the minimap clock above rim icons with an addon-owned overlay that leaves Blizzard clock geometry untouched.
  Recolour player health through a secure post-hook instead of writing shared unit-frame control state.
  Detect persistent target-of-target detachment and require a direct user click for every protected repair and reload, including the labelled Classic Era cleanup pass.
  Add regression coverage for clock draw order, unit-frame taint boundaries, protected repair authority, and release-version consistency.

v0.2.0

HelloUI

v0.2.0 (2026-07-27)

Full Changelog Previous Releases

• Release v0.2.0 with custom status bars
  Render compact addon-owned XP, rested XP, and watched-reputation bars without changing Blizzard status-manager geometry. Hide XP at level cap and compact a lone visible status bar into the bottom slot.
  Refine the Edit Mode layout with full-size left-aligned stance buttons, a taller raised chat frame, and additional clearance below the action bars. Remove protected panel refreshes and the shared Blizzard dropdown path to prevent Game Menu callback taint.

v0.1.0

HelloUI

v0.1.0 (2026-07-26)

Full Changelog

• Build the layout when a profile is created, and switch it when one is chosen
  A new profile changes the layout's NAME - "HelloUI - " - and nothing
  created a layout under that name, so Edit Mode stayed on the old profile's
  layout, IsActive answered no, and the login prompt asked for a layout the
  player had already accepted on the profile they copied from. Every session.
  Config's profile writes now call Layout:FollowProfile, which:
  - does nothing at all if HelloUI's layout was not active before the switch.
  "Asked, never applied silently" has to survive this: consent carries across
  a profile switch, it is not created by one. Read BEFORE the switch, since
  afterwards the question is about the layout we just moved to.
  - ACTIVATES an existing layout rather than re-applying it. Apply rebuilds the
  systems table from current settings, which is right when you ask for the
  layout and wrong when you merely switch to a profile that has one: Edit Mode
  saves your dragging into the layout, so a rebuild throws it away. New
  Layout:Activate only changes which layout is active.
  - builds one with Apply only when the profile has no layout yet - the case in
  the report - and defers to PLAYER_REGEN_ENABLED if that lands in combat.
  The Edit Mode nudge (show then hide the manager, which is what makes it re-read)
  is now a shared helper instead of living inside Apply, since Activate needs it
  too. IsActive takes an optional layout name for the same reason.
  352 checks. One mutation initially survived - rebuilding instead of activating -
  because the assertion held a table captured before the switch, and GetLayouts
  hands back copies, so the stale snapshot kept the marker the live layout had
  lost. It re-reads from the client now and the mutation fails.
• Add an addon-list icon, cropped from the project art
  64x64, matching HelloWarrior's, with the TOC's IconTexture pointing at it.
  Cropped rather than scaled: HelloUI.png is a logo card - monogram badge, "Hello
  UI" wordmark, tagline, mock UI around the border - and squashing 1254px of that
  into 64 turns the wordmark into three grey smears. The HU badge is the part that
  survives at icon size, so the crop is just the badge and its ring.
  Framed by measurement rather than by eye, after two attempts that missed: a
  labelled grid over the source put the ring and its four diamond points at
  x 425-820, y 55-500, and the final 438px window at (629, 288) holds all four
  points while clearing the mock health bars on the left and the mock minimap on
  the right - both of which a looser crop dragged in as coloured specks.
  Icon.png ships in the zip; HelloUI.png still does not.
• Release plumbing, pointed at CurseForge project 1625608
  The project ID on its own does nothing: it is read by the BigWigs packager,
  and HelloUI had no packager config and no workflow to run it. Ported from
  HelloWarrior, which is the family's working version of this.
  .pkgmeta what ships in the zip
  .github/workflows/release.yml fires on a v* tag, checks the tag against the
  TOC version, packages, uploads to CurseForge
  and cuts a GitHub Release
  .github/changelog.sh builds the release notes with commit trailers
  filtered out, which the packager cannot do
  .gitignore the generated CHANGELOG.md, .DS_Store, .claude/
  Two differences from HelloWarrior's copy, both about what this addon has that
  it does not: Tests/ and .luacheckrc are excluded from the zip - the harness
  stubs the entire client API to run under plain lua and would never be read in
  game - and HelloUI ships no IconTexture, so nothing needs keeping for the
  client.
  Also tracks HelloUI.png, the CurseForge project image, and excludes it from the
  zip for the same reason HelloWarrior excludes its own: the page needs it, the
  player does not.
  Still needed before a release can happen: the GitHub repo (HelloUI has no
  remote yet) and a CF_API_KEY secret on it. Without the key the workflow still
  cuts a GitHub Release and just skips the CurseForge upload.
• Profiles: settings per profile, characters pick one
  Every setting lived at the top level of HelloUIDB and applied to all 47
  characters, with a sparse per-character override list beside it. That shape came
  from the DragonflightUI profile being ported - one arrangement, one diverging
  character - and it is the wrong shape for alts you play differently, because it
  makes you enumerate the exceptions.
  Settings now live in HelloUIDB.profiles[name] and HelloUICharDB stores which one
  this character uses. Get and Set resolve through the active profile; there is no
  account/override split left to reason about.
  What deliberately does NOT go in a profile: xpBarTextOriginal and proxyOriginals
  • HelloUI's memory of what Blizzard's state was before it touched anything - and
    the migration latches. Those are not preferences, and copying them per profile
    would mean a profile switch could hand the client back the wrong original.
    The Edit Mode layout follows the profile: Default keeps the bare "HelloUI",
    anything else gets "HelloUI - ", always Account-typed since a profile
    is shareable and a character is not. That collapses layoutPerCharacter into the
    profile choice - one decision instead of two that could disagree.
    Migration, latched on profilesV1: the old top-level settings become Default, and
    a character with overrides gets a profile named after itself seeded with them.
    The name is not cosmetic - the old per-character layout was "HelloUI - ",
    so the layout that character already has is the layout it keeps.
    /hui char becomes /hui profile [use|new|delete]; the panel gains a Profile
    section with a dropdown, following HelloBuffCap's, which is the family's only
    precedent for one on this client.
    343 checks. Eight mutations tried, all caught: profiles sharing one table, a new
    profile starting blank instead of copying, settings left at the top level,
    remembered originals swept into a profile, overrides ignored by the migration, a
    deleted profile resurrected at login, the layout ignoring the profile, and
    Default being deletable.
• File the addon under UI Overhaul
  The same category DragonflightUI sits in, which is where somebody looking for
  its replacement will look. One English line, matching every sibling - the family
  declares a bare ## Category: and none of them carry the ten localised variants
  DragonflightUI ships, and the client falls back to this line for any locale that
  has no override.
  Worth noting the tension rather than pretending it away: the Notes line still
  says "no art overhaul", and that is still true - the category describes the
  shelf, not the method.
• Darkmode is one switch
  The desaturate toggle, the four per-area checkboxes and the tint colour are
  gone. Nobody was going to tint the minimap but not the cast bar, and the grey
  was three numbers with no way to change them short of editing saved variables.
  On desaturates and tints every texture on the allowlist; off hands all of them
  back. The tint is a constant in Darkmode.lua.
  The entries lose their area tag with the gating, and Status stops printing a
  list of areas that can no longer differ. Three more keys join the retired list
  and are deleted from saved variables - including darkmodeAreas, which the
  harness now plants as a TABLE with two areas set false, since that is the shape
  a real install carries. Darkmode must still cover everything with those on file.
• Remove the button border feature
  Taking ActionButtonTemplate's NormalTexture from Blizzard's alpha="0.5" to full
  shipped on the reasoning that hiding the bar backdrop takes the per-slot
  recesses with it. Seen on screen, the stock half-alpha border is preferred, and
  looking at it is the only thing that settles a look.
  Nothing writes that texture now in either direction - not to set it, not to
  restore it - so the buttons carry exactly what Blizzard ships. The key joins the
  retired list and is deleted from saved variables on sight.
  The harness assertion inverts with the feature: the border alpha is set to 0.42
  first, something Blizzard never uses, then ApplyAll must leave it there. Both
  "the feature came back" and "a restore path that still writes 0.5" fail that,
  where asserting a bare 0.5 would have passed the second one.
• Stop asking for the layout that is already active
  Layout:IsActive compared an index into the SAVED-only list GetLayouts returns
  against activeLayout, which counts the presets first. On Era that is 1 against
  3, so it answered "not active" for a layout that plainly was, and MaybeAsk
  raised the login prompt every single session.
  This is the same asymmetry that made the first version of Apply switch to a
  Blizzard preset, and Apply has done the [presets..., saved...] rebuild ever
  since. IsActive never did. Both go through one combinedLayouts helper now,
  because having the rebuild in one caller and not the other IS the fail...