Move GUI:CloseAllMenus back resident, with its registry

Four lines, and having them in the companion split a three-part unit across an
addon boundary for no benefit: the registry table and RegisterMenu were
resident while the only thing that reads the registry was not. Resident code
could add a menu but not close one, and resident CreateDropdown does register
(the mover panel's anchor dropdown is a resident caller).

Nothing was broken -- both callers are companion-side, so reader and callers
loaded together -- but the failure mode if anyone had reached for it from
resident code was the bad kind: a bulk 'dismiss whatever is open' call that is
nil half the time fails SILENTLY, leaving a menu floating, which is the exact
symptom the registry exists to prevent.

Taking the fix rather than documenting the wart, which is also the lesson from
the two ORDER-IS-LOAD-BEARING claims this review found to be false: a comment
describing a split is worse than not having the split.

gui-conventions.md updated to match -- it now says all three pieces are
resident and should stay together, keeps the reasoning as a note on why, and
still distinguishes CloseAllMenus from CloseOpenDropdown (resident, on _priv,
the single-open-dropdown case most call sites actually want).

Author: Krathe82

DandersFrames/GUI/Widgets.lua

@@ -1822,6 +1822,20 @@ end
 GUI._menus = GUI._menus or {}
 function GUI:RegisterMenu(frame) self._menus[frame] = true end
 
+-- ☠ Lives with the registry it iterates, deliberately. This was in the
+-- companion for a while, which left resident code able to REGISTER a menu but
+-- not close one -- and resident CreateDropdown below does register (the mover
+-- panel's anchor dropdown is a resident caller). Nothing broke, because both
+-- callers happened to be companion-side, but a bulk "dismiss whatever is open"
+-- call that is nil half the time fails SILENTLY: the menu just stays floating,
+-- which is the exact symptom this registry exists to prevent. Four lines is
+-- not worth an addon boundary.
+function GUI:CloseAllMenus()
+    for f in pairs(self._menus) do
+        if f:IsShown() then f:Hide() end
+    end
+end
+
 function GUI:CreateDropdown(parent, label, options, dbTable, dbKey, callback, customGet, customSet, opts)
     opts = opts or {}
     local accentColor = opts.accent

DandersFrames_Options/GUI/SettingsWidgets.lua

@@ -1922,12 +1922,6 @@ function GUI:CreateColorPicker(parent, label, dbTable, dbKey, hasAlpha, callback
     return container
 end
 
-function GUI:CloseAllMenus()
-    for f in pairs(self._menus) do
-        if f:IsShown() then f:Hide() end
-    end
-end
-
 function GUI:CreateOutlineDropdown(parent, label, dbTable, dbKey, callback, inheritKey)
     local options = {
         NONE = L["None"],

docs/gui-conventions.md

@@ -182,7 +182,7 @@ one surface behave unlike the rest of the addon.
 
 | Need | Helper | ☠ What breaks if you skip it |
 |------|--------|------------------------------|
-| A dropdown-style popup menu | `GUI:RegisterMenu(frame)` — resident; `GUI:CloseAllMenus()` — **companion-only, see below** | **Register every menu frame at creation.** A menu that isn't registered stays open through a page change, mode switch or window close, and floats over whatever comes next |
+| A dropdown-style popup menu | `GUI:RegisterMenu(frame)`, `GUI:CloseAllMenus()` | **Register every menu frame at creation.** A menu that isn't registered stays open through a page change, mode switch or window close, and floats over whatever comes next |
 | A widget that changes height | `GUI:RelayoutHost(widget, slotHeight)` | Updates the group's stored slot, re-lays the group, **then bubbles to the page** so sibling groups re-anchor. Without the bubble a grown group's backdrop overshoots the next group's anchor and paints an empty rectangle above it |
 | A border on a bespoke frame | `GUI:ApplyPixelBorder(frame, {r,g,b,a}, weight)`, `GUI:HidePixelBorder(frame)`, `GUI:RefreshPixelBorders()` | Our two-device-pixel border. A `SetBackdrop` edge instead gives you the thinning / vanishing hairline the whole system exists to avoid — see "The pixel grid" |
 | Whole-pixel geometry | `GUI.SnapLen`, `GUI.SnapLenUp` | Right/top edges land mid-pixel and clip whatever they contain |
@@ -192,36 +192,32 @@ one surface behave unlike the rest of the addon.
 | Colour-picker interop | `GUI:InstallColorPickerHook()` / `Uninstall…` / `IsColorPickerHookInstalled()` / `MarkColorPickerCall()` | Keeps Blizzard's picker from stomping our own; mark your call or the hook can't tell whose it is |
 | Section collapse state | `GUI:GetCollapsedGroups()` | Persisted collapse state — read it, don't track your own |
 
-### ⚠ The menu registry straddles the addon boundary
+### The menu registry — all three pieces are resident
 
-The three pieces of the menu system do not live together, which the table above
-cannot show:
+The registry table, its writer and its reader live together in
+`DandersFrames/GUI/Widgets.lua`, and they should stay that way:
 
-| Piece | Where | Loads |
-|---|---|---|
-| `GUI._menus` (the registry table) | `DandersFrames/GUI/Widgets.lua` | always |
-| `GUI:RegisterMenu(frame)` | `DandersFrames/GUI/Widgets.lua` | always |
-| `GUI:CloseAllMenus()` | `DandersFrames_Options/GUI/SettingsWidgets.lua` | with the settings panel |
-
-So **resident code can register a menu but cannot close one.** Resident
-`GUI:CreateDropdown` registers its menu frame, and it has one resident caller —
-the mover panel's anchor dropdown (`Frames/Position.lua`), which exists with
-the settings panel unloaded.
-
-Nothing is broken today: both `CloseAllMenus` callers are companion-side
-(`AuraDesigner/UI/Cards.lua`), so the reader and its callers load together. But
-if you are writing resident code and reach for `CloseAllMenus`, **it will be
-nil until someone has opened `/df`** — and because it is a bulk "tidy up"
-call, a nil-guard that skips it fails silently by leaving a menu floating,
-which is exactly the symptom the registry exists to prevent.
-
-If you need it resident, move the function rather than guarding the call: it is
-four lines and it belongs with the registry it iterates. Guarding would
-document the split instead of removing it.
-
-☠ Not the same thing as `CloseOpenDropdown` (resident, published on
-`GUI._priv`), which closes the *single currently-open* dropdown. That one is
-available on both sides and is what most call sites actually want.
+| Piece | Where |
+|---|---|
+| `GUI._menus` (the registry table) | resident |
+| `GUI:RegisterMenu(frame)` | resident |
+| `GUI:CloseAllMenus()` | resident |
+
+`CloseAllMenus` briefly lived in the companion during the load-on-demand split.
+That left resident code able to *register* a menu but not close one — and
+resident `GUI:CreateDropdown` does register, with a resident caller (the mover
+panel's anchor dropdown). Nothing broke, because both `CloseAllMenus` callers
+happened to be companion-side, but the failure mode was the bad kind: a bulk
+"dismiss whatever is open" call that is nil half the time fails **silently**,
+leaving a menu floating — the exact symptom the registry exists to prevent.
+
+☠ Four lines are not worth an addon boundary. If you ever find yourself
+nil-guarding a call like this, move the function instead — a guard documents
+the split rather than removing it.
+
+Not the same thing as `CloseOpenDropdown` (resident, published on `GUI._priv`),
+which closes the *single currently-open* dropdown. That is what most call sites
+actually want.
 
 ## Popups — never Blizzard's