- the world map speaks the reference's names: WorldMapTooltip is declared (six corpus addons index it; pfUI dies on it at file scope), the blackout frame takes the reference's spelling BlackoutWorld, and the four hand-written party blips become the reference's own unit-blip templates — all 44 blips as instances, each with its published $parentIcon, the name pfUI recolours group blips by class through; the 40 raid ones are declared but not positioned yet, named in the OUT list rather than faked
- the templates addons build their own buttons from are published: ItemButtonTemplate, ContainerFrameItemButtonTemplate and the bag-slot chain — most of the handler scripts were live the whole time (this client executes the reference's own container and paper-doll code off the player's patch chain), so what was missing was mostly declarations, not behaviour — the bank arm stays out and is named as the omission it is; OptionsFrameSliders becomes real, with the three Graphics rows reading it and re-reading on show, so an addon's write to a slider's bounds actually moves the slider; and the template census that had ranked these at "zero demand" learns to see a local bound to a literal — its table went from 3 rows to 7
- the bindings answer in 1.12's own shapes: Button:IsEnabled() answers the NUMBER 1 or 0 (0 is truthy in Lua, so the reference's own == 0 tests got false forever, and three of our files had hand-worked around the divergence rather than fixed it); the constructors' string arguments are four shapes, not one rule — pfUI passes a Button where a template name goes and the reference constructs the FontString and ignores it; SetInventoryItem returns THREE values, the reference's own paper doll destructuring repairCost; UnitIsVisible is object presence and nothing else (57 bytes, one branch, no distance — an out-of-range party member is exists-yes, visible-nil); the tapped pair reads the two dynamic-flags bits, and its repaint wire fires UNIT_FACTION on the tap bit — the half a passing predicate test never sees; UnitIsPartyLeader is two ORed legs covering disjoint failures (a held stranger leading their own party, and an out-of-range member with no object to read a flag from); and the four nameplate verbs take no argument and return zero values
- the ghost's wisps compose onto its body instead of over it — the four emitters drew at full strength over a body at alpha 0.5, and now inherit the instance alpha down the attachment chain the way the reference recomposes it per frame; the residual we had parked ("the wisps should inherit the tint too") is REFUTED at the bytes: a particle batch commits hardcoded white RGB, and even that never reaches the fragment — particles are never tinted, only the alpha crosses, applied to the alpha byte alone — so the shipped shader split was already right and no code changes
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
103 lines
6.4 KiB
XML
103 lines
6.4 KiB
XML
<!--
|
|
The reference's item-SLOT button templates: `PaperDollItemSlotButtonTemplate` (PaperDollFrame.xml
|
|
l.4-38) and `BagSlotButtonTemplate` (MainMenuBarBagButtons.xml l.17-53), which inherits it. Both
|
|
sit on `ItemButtonTemplate` (ItemButtonTemplate.xml), so the chain is
|
|
|
|
ItemButtonTemplate <- PaperDollItemSlotButtonTemplate <- BagSlotButtonTemplate
|
|
|
|
and all three are now declared, in that order, across three files the toc loads in that order.
|
|
|
|
**Why they are here rather than in CharacterFrame.xml and BagFrame.xml, where their subjects
|
|
live.** Load order, and only load order: BagFrame.xml (toc l.241) comes BEFORE
|
|
CharacterFrame.xml (l.256), so a bag template declared in the former could not inherit a doll
|
|
template declared in the latter. Neither is consumed by our own windows — our doll slots and our
|
|
four bag-bar slots are hand-wired to `BenillaPaperDollSlot_*` / `BenillaBagBarSlot_*` and do not
|
|
inherit these — so a file of their own, loaded after both, costs nothing and makes the chain
|
|
readable. This is the reference's published surface for ADDONS, kept where its dependencies are
|
|
satisfied.
|
|
|
|
**The handlers are the reference's own, not transcriptions.** `PaperDollItemSlotButton_OnLoad`,
|
|
`_OnEvent`, `_OnClick`, `_Update`, `_UpdateLock`, `_OnEnter` and `_OnUpdate` come from
|
|
`PaperDollFrame.lua`, which `ui_script::reference_ui` now SOURCES off the player's own patch
|
|
chain. That file earned its place because every one of those acts on `this` and `this:GetID()`
|
|
through live APIs and never on a named reference window — see the note beside SOURCED for what
|
|
was checked first, including the 18 collisions that order settles in our favour.
|
|
|
|
`MainMenuBarBagButtons.lua` is deliberately NOT sourced, which is why `BagSlotButton_OnClick`,
|
|
`_OnDrag`, `_OnShiftClick` and `_OnEnter` are ours in BagFrame.xml: all four of its versions walk
|
|
`ContainerFrame1..NUM_CONTAINER_FRAMES`, windows this client does not build, and two of them
|
|
call verbs (`PutItemInBag`, `PickupBagFromSlot`) it does not bind. Sourcing it would have handed
|
|
every caller a body that raises inside the addon's own click wrapper.
|
|
|
|
**pfUI is the measured caller**, and it fits the reference's contract exactly rather than by
|
|
luck: it names its bag-bar buttons `pfUIBagsBBag0Slot`.. with a NINE-character prefix, so the
|
|
reference's own `strsub(name, 10)` in `PaperDollItemSlotButton_OnLoad` yields `Bag0Slot` and
|
|
`GetInventorySlotInfo` answers slot 20. It then reads `$parentIconTexture`, `$parentNormalTexture`,
|
|
`GetHighlightTexture()` and `GetPushedTexture()` off what it built, and CHAINS the template's
|
|
OnEnter/OnLeave rather than replacing them (modules/bags.lua l.513-585).
|
|
|
|
OUT, named rather than stubbed (1134 §4): the bank arm. `BankItemButtonBagTemplate` and
|
|
`BankItemButtonGenericTemplate` inherit `BankItemButtonTemplate`, whose handlers live in
|
|
`BankFrame.lua` — not sourced — and whose OnEnter calls `this:GetInventorySlot()`, a widget
|
|
method we do not bind. pfUI reaches those only for its bank window.
|
|
-->
|
|
<Ui xmlns="http://www.blizzard.com/wow/ui/">
|
|
<!-- Ref PaperDollFrame.xml l.4-38, structure and scripts verbatim. The `$parentCooldown` Model
|
|
is not optional decoration: the sourced `PaperDollItemSlotButton_Update` resolves it by
|
|
name (`getglobal(this:GetName().."Cooldown")`) and calls `:Hide()` / CooldownFrame_SetTimer
|
|
on it every repaint, so a button without one raises on its first update. -->
|
|
<Button name="PaperDollItemSlotButtonTemplate" inherits="ItemButtonTemplate" virtual="true">
|
|
<Frames>
|
|
<Model name="$parentCooldown" inherits="CooldownFrameTemplate"/>
|
|
</Frames>
|
|
<Scripts>
|
|
<OnLoad>PaperDollItemSlotButton_OnLoad();</OnLoad>
|
|
<OnEvent>PaperDollItemSlotButton_OnEvent(event);</OnEvent>
|
|
<OnClick>PaperDollItemSlotButton_OnClick(arg1);</OnClick>
|
|
<OnShow></OnShow>
|
|
<OnDragStart>PaperDollItemSlotButton_OnClick("LeftButton", 1);</OnDragStart>
|
|
<OnReceiveDrag>PaperDollItemSlotButton_OnClick("LeftButton", 1);</OnReceiveDrag>
|
|
<OnEnter>PaperDollItemSlotButton_OnEnter();</OnEnter>
|
|
<OnLeave>
|
|
this.updateTooltip = nil;
|
|
GameTooltip:Hide();
|
|
ResetCursor();
|
|
</OnLeave>
|
|
<OnUpdate>PaperDollItemSlotButton_OnUpdate(arg1);</OnUpdate>
|
|
</Scripts>
|
|
</Button>
|
|
|
|
<!-- Ref MainMenuBarBagButtons.xml l.17-53. A CheckButton over a Button template — the checked
|
|
ring is the "this bag's window is open" light, which is why the type changes at this rung.
|
|
`$parentItemAnim` is the ref's item-push card; ours is BenillaItemPushAnim_* (0887), and the
|
|
template cannot carry it because the reference's ItemAnimTemplate binds a per-instance
|
|
container id our four hand-wired slots pass explicitly. A template-built button therefore
|
|
gets no push animation, which is a missing flourish and not a missing behaviour. -->
|
|
<CheckButton name="BagSlotButtonTemplate" inherits="PaperDollItemSlotButtonTemplate" virtual="true">
|
|
<Scripts>
|
|
<OnLoad>
|
|
PaperDollItemSlotButton_OnLoad();
|
|
this:RegisterEvent("BAG_UPDATE");
|
|
this.isBag = 1;
|
|
-- OURS, and the one deviation in this file's scripts. The reference's three bag
|
|
-- handlers each recompute a `translatedID` from these same two ids at every call
|
|
-- site; our bodies read `button.bagId`, the field BenillaBagBarSlot_OnLoad sets for
|
|
-- the four hand-wired slots. Resolving it once here is what lets a template-built
|
|
-- button and a hand-wired one share one implementation instead of two.
|
|
this.bagId = this:GetID() - CharacterBag0Slot:GetID() + 1;
|
|
</OnLoad>
|
|
<OnClick>
|
|
if ( IsShiftKeyDown() ) then
|
|
BagSlotButton_OnShiftClick();
|
|
else
|
|
BagSlotButton_OnClick();
|
|
end
|
|
</OnClick>
|
|
<OnDragStart>BagSlotButton_OnDrag();</OnDragStart>
|
|
<OnReceiveDrag>BagSlotButton_OnClick();</OnReceiveDrag>
|
|
<OnEnter>BagSlotButton_OnEnter();</OnEnter>
|
|
</Scripts>
|
|
<CheckedTexture alphaMode="ADD" file="Interface\Buttons\CheckButtonHilight"/>
|
|
</CheckButton>
|
|
</Ui>
|