v1.0.9

MountsJournal EllesmereUI Skin

v1.0.9 (2026-07-31)

Full Changelog Previous Releases

• Wire up CurseForge uploads (project 1633540)
  The packager reads the project ID from the TOC and authenticates with the
  CF_API_KEY repo secret, so from this tag on every release lands on GitHub
  and CurseForge in the same run.
  Co-Authored-By: Claude Fable 5 noreply@anthropic.com
• Add a CurseForge-ready copy of the project description
  The README leans on things CurseForge's Markdown mode does not have: an HTML
  centering wrapper, relative image paths into docs/, and relative links into
  the repo. This copy is plain Markdown with absolute URLs throughout, images
  served from raw.githubusercontent, and the GitHub-specific installing section
  dropped. Lives in docs/, which .pkgmeta already keeps out of the shipped zip.
  Co-Authored-By: Claude Fable 5 noreply@anthropic.com

v1.0.8

MountsJournal EllesmereUI Skin

v1.0.8 (2026-07-31)

Full Changelog Previous Releases

• Bring the map control row flush with the flags panel edges
  The dnr button and the lists toggle stopped a hairline short of the panel
  below them, which reads as a few pixels at screen scale. The surface they
  should line up with is the flags panel background, and that background is
  drawn on mapSettings, so the row's outer edges now anchor to mapSettings
  itself at 0 rather than 1px inside mapControl. Anchoring to the frame that
  owns the background keeps the edges matched even if mapControl's own anchors
  ever change.
  Co-Authored-By: Claude Fable 5 noreply@anthropic.com

v1.0.7

MountsJournal EllesmereUI Skin

v1.0.7 (2026-07-31)

Full Changelog Previous Releases

• Print addon versions in the diagnostic
  The skin addresses frames by path, so which MountsJournal and EllesmereUI
  versions are installed is the first question every bug report raises. Print
  all three from the slash command, resolved only when it runs, and above the
  inert bail-out, since an inert report needs them most.
  Co-Authored-By: Claude Fable 5 noreply@anthropic.com

v1.0.6

MountsJournal EllesmereUI Skin

v1.0.6 (2026-07-31)

Full Changelog Previous Releases

• Re-resolve LibSFDropDown after MountsJournal's UI addon loads
  The library ships inside MountsJournalUI, which loads on demand after our
  PLAYER_LOGIN dispatch, so the one-shot resolution at skin time ran before the
  library existed and every menu kept its stock backdrop: the permanent
  "dropdown menu style: NO" with all stages ok. Retry from skinUI, which only
  runs once MountsJournalFrame exists and therefore after that addon has
  loaded. The resolver is now guarded so the second call is a no-op where the
  first one already worked.
  Co-Authored-By: Claude Fable 5 noreply@anthropic.com

v1.0.5

MountsJournal EllesmereUI Skin

v1.0.5 (2026-07-31)

Full Changelog Previous Releases

• Adopt the 8.6.8 skinning API as a hybrid, and fix the DressUp button
  EllesmereUI 8.6.8 ships RegisterSkin, but two things the day-of cross-check
  found change how we take it:
  The parent ships the stub even when the Blizzard Skin child addon is
  disabled, as a documented silent no-op, so selecting the api backend on the
  function existing would leave the journal wholly unskinned there. The gate is
  now the child's dispatcher; without it we fall back to compat, which works in
  full on 8.6.8.
  And three engine primitives do not reproduce this skin's look: Shell (opaque
  atlas, 25px title bar, no Dark Mode fill or alpha), ScrollBar (no groove,
  stripped arrows, centre-strip thumb, classic sliders skipped), and Checkbox
  (border proud of the box by its 4px inset). The api backend therefore runs a
  hybrid facade: those three plus RefreshLooks stay ours, everything else is
  EllesmereUI's, and our RefreshLooks is registered with the engine's
  OnLooksChanged, so a live accent edit now repaints the window without a
  reload. The backdrop, opacity and edge options keep working on both backends.
  The DressUp button's whole visual is its unnamed Normal/Pushed art, which
  S.Button faded, leaving a blank block with a hover tint aimed at invisible
  textures. Park the art on keys and name it through keepKeys, the same dance
  as dynamicFlightButton.
  Co-Authored-By: Claude Fable 5 noreply@anthropic.com

v1.0.4

MountsJournal EllesmereUI Skin

v1.0.4 (2026-07-31)

Full Changelog Previous Releases

• Stop touching the bottom tab row, and fix the arrow hover art
  TABS. Reverted entirely: not the art, not the position, not the labels.
  Two attempts to improve that row both ended worse than doing nothing.
  Flattening it lost the native selected-tab growth, because the growth IS
  the taller activetab atlas, so fading the art removes the very thing that
  made the tab read as selected. Adding a base under the wash then made the
  current tab a pale plate instead. Seating it flush removed a 2px overlap
  the native art is drawn to have.
  Untouched, these are the same Blizzard template as Collections' tabs and
  behave identically, growth included. That was the state that looked
  right, and nothing since has beaten it.
  ARROW HOVER. The square plate appearing around the crumb arrow is the
  template's own doing: it ships its Normal and Pushed art at alpha 0 and
  raises it from the button's mouse scripts, so a fade at skin time is
  undone the moment the cursor arrives. Re-zero from those same scripts,
  which run after the template's.
  Third time this pattern has bitten, after the search box anchor and the
  tab labels: a build-time fix that a runtime path overwrites. Anything
  that looks correct until you interact with it is this.
  Co-Authored-By: Claude Opus 5 noreply@anthropic.com

v1.0.3

MountsJournal EllesmereUI Skin

v1.0.3 (2026-07-31)

Full Changelog Previous Releases

• Give the tab row a base under its wash
  Fading the art was right and incomplete. /mjeuiskin tabs shows
  Collections' tabs carrying three slices at full alpha and three more at
  0.40 UNDERNEATH their 15% white wash, so that wash lands on something
  solid. Ours had the art faded and the wash alone, and for a row that
  hangs below the window frame the thing behind it is the game world, so a
  10% white wash read as a pale haze rather than a tab.
  Add a base in the house panel tone under the wash, and soften the wash
  now that it has something to sit on.
  The report was missing the value that would have shown this: a texture
  with no file printed as "colour" and said nothing about whether it was a
  dark plate or a white one. It now prints vertex colour alongside size and
  alpha, so a base and a haze are distinguishable in the output rather than
  only on screen.
  Co-Authored-By: Claude Opus 5 noreply@anthropic.com

v1.0.2

MountsJournal EllesmereUI Skin

v1.0.2 (2026-07-31)

Full Changelog Previous Releases

• Fade the tab art instead of clearing its texture
  The bottom tab row came out as pale silver blocks. SetTexture("") does
  not make an atlas region draw nothing, it falls back to a plain white
  texture, and those six regions sit at alpha 1.00 and 0.40, so the row
  stacked up into light grey.
  The window engine makes the same call safely because it then covers the
  tab with an opaque plate. We lay a 10% wash instead, so whatever is left
  underneath shows through. Fade the regions to alpha 0, which is what the
  rest of the addon does and what its stated policy has always been; the
  hover art is still left alone so the row answers the mouse.
  Also bring the map control row out to a 1px hairline off its container at
  both ends. The 3px inset was stock spacing sized for art with its own
  transparent margin, and once flattened it read as the row not reaching
  the panel around it.
  Co-Authored-By: Claude Opus 5 noreply@anthropic.com

v1.0.1

MountsJournal EllesmereUI Skin

v1.0.1 (2026-07-31)

Full Changelog Previous Releases

• Match the nav bar row heights and skin the crumb dropdowns
  Read from the templates rather than guessed. MJNavButtonTemplate is 28
  tall; the home and overflow buttons come from Blizzard's NavBarTemplate
  at 24. The chevron art hid that difference and flat blocks do not, so the
  row had two odd ones out. Both are now 28.
  The overlap has a proper fix. xoffset is a real NavBar field and both
  ship with a large negative one, -15 on home and -18 on overflow, so the
  next button slides back underneath their chevron overhang. That is what
  buried the overflow arrow on a deep trail. Setting a 1px seam on those
  two as well as the crumbs fixes it at the anchor instead of relying on
  the frame level raise, which stays as a backstop.
  The crumb dropdown arrow is a child button carrying its own
  SquareButtonTextures art, so flattening the crumb never reached it. It
  now gets the same arrow S.Dropdown draws, which is what the map's own
  navigation button already had.
  Co-Authored-By: Claude Opus 5 noreply@anthropic.com

v1.0.0

MountsJournal EllesmereUI Skin

v1.0.0 (2026-07-31)

Full Changelog Previous Releases

• Initial release
  Reskins MountsJournal to match EllesmereUI, following the user's own
  EllesmereUI settings rather than a look of its own: window colour and
  transparency from the active profile's Dark Mode fill, accent, UI font,
  and window border all read live and never cached, so a profile switch is
  picked up without configuration.
  Works on EllesmereUI 8.6.6 and later. Where EllesmereUI.RegisterSkin
  exists the official skinning API is used; where it does not, an
  equivalent facade is rebuilt from the public helpers 8.6.6 exports. The
  switch is automatic and /mjeuiskin reports which is live.
  Art removal is alpha-only -- nothing is Hide()n, reparented or has its
  scripts replaced, and all hooking is HookScript/hooksecurefunc. Blizzard's
  Collections and MountJournal chrome is suppressed only while the journal
  is open, by geometry, and restored on close. No OnUpdate, no polling, no
  per-frame work; registries are weak-keyed so pooled rows stay collectable.
  Every skinning stage is isolated, so a frame that moves in a future
  MountsJournal update costs that section rather than the window, and
  /mjeuiskin names it.
  Derivative of MountsJournal_ElvUI_Skin by sfmict (GPLv3): the map of which
  frames need skinning comes from there, the EllesmereUI implementation is
  new. Thanks to sfmict, who wrote both MountsJournal and that skin, and to
  EllesmereGaming for EllesmereUI.
  Co-Authored-By: Claude Opus 5 noreply@anthropic.com