Files
benilla-octo/crates/benilla-app/assets/ui/ItemSlotButtonTemplates.xml
T
SamandClaude Fable 5 a0d2fc383b the world map blips are the reference's, and particles go untinted
- 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>
2026-08-31 20:15:16 +07:00

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>