New mod: Tray Utility Customizer

[sb4ssman]

Adds Tray Utility Customizer (v1.0): arranges the low-frequency Windows 11 tray utility controls — Show hidden icons (overflow chevron), Emoji and more, touch keyboard, pen menu, virtual touchpad, and the input indicator — into one compact row, column, or smart grid.

Highlights:

• Moves the native tray hosts instead of drawing replacement buttons or forwarding clicks; controls, flyouts, and tooltips stay Windows-owned. Placement is margin-based so flyouts anchor at the control's real position.
• Smart automatic grid sized from the item count and current taskbar height (great for double-height taskbars), plus single row/column and fixed grid modes with fill order and short row/column placement and alignment.
• Position by borrowing the hidden-icons or Emoji column, or by leasing a dedicated, marker-tracked tray column (before icons / before network-volume-battery / before or after clock / after Show Desktop). Two experimental Start-adjacent positions relocate the group beside the Start button.
• Reacts to live changes: utilities toggled off in taskbar settings or transient controls (touch keyboard) release their cell and the grid re-adapts and re-centers automatically.
• Fully reversible: snapshot-and-marker restore returns every host to its native column, size, and alignment on unload.

Screenshots (also embedded in the mod readme):

Tested live on Windows 11 (primary taskbar): default configuration, smart grid on single- and double-height taskbars, borrowed and dedicated positions, flyout/tooltip/right-click behavior, settings reload, taskbar-settings toggles of managed utilities, Explorer restart, and disable/unload restore.

Changelog

If this pull request updates an existing mod, describe the changes below:

• New mod submission — no changelog.

Mod authorship

If this pull request introduces a new mod, please complete the section below.

This mod was created by:

• • The submitter, without AI assistance
• • The submitter, with AI assistance
• • Claude
• • ChatGPT
• • Gemini
• • Another AI (please specify):
• • Other (please specify):

Please select the options that best apply. Your selection does not affect the acceptance criteria, but it helps reviewers understand the context of the code and provide relevant feedback.

🤖 Generated with Claude Code

[m417z]

Regarding item 1, you can look at how the Taskbar tray system icon tweaks mod handles this. If only English is supported for now, I think it's worth adding it to the readme.

Submission review

Note: This review was done by Claude, and then refined manually. Due to the amount of submissions, doing a fully manual review for each pull request is no longer feasible. Thank you for understanding.

Please address the following issues. The items in the collapsed sections are optional, so it's your call whether to address them.

---

1. Utility detection keys off English accessibility text, so most utilities won't be found on non-English Windows. FindUtilityElement / MetadataContainsAny search the lowercased concatenation of Name + AutomationId + AutomationProperties::GetName + GetHelpText for English substrings — L"touch keyboard", L"pen menu", L"virtual touchpad", L"input indicator" / L"language bar". Those accessibility names are localized by Windows (e.g. German "Bildschirmtastatur", "Stiftmenü", "Virtuelles Touchpad"), so on a non-English UI these tokens silently won't match and the utility is reported "not found." The two defaults happen to survive — overflow keys off the stable element name NotifyIconStack and emoji off the loanword "emoji" — but everything else quietly won't be gathered. Note that the overflow case already shows the robust approach: keying off a language-neutral element Name. Where a stable Name/AutomationId exists for the other hosts, prefer matching that; otherwise, please at least document the English-only detection limitation in the README so non-English users know why a selected utility isn't picked up.

2. The enabled option. Does it just disable the mod? Why is it needed?

3. The IconView::IconView hook: the only reason you use is to apply the layout with retries. Hooking TrayUI::StartTaskbar instead will remove the dependency on SystemTray.dll, Taskbar.View.dll, ExplorerExtensions.dll, simplify the code, and reduce the chances of the mod breaking with updates.

   Also, why is g_retryThread needed as well?

4. GetTaskbarXamlRoot - add ARM64 support. Use one of the mods, e.g. taskbar-start-button-position, as a reference.

Optional improvements

Minor polish — none of this affects users, so it's your call.

• GetStringSetting's NULL check is unnecessary. Wh_GetStringSetting never returns NULL (it returns L"" when unset/on error), so value ? value : L"" and the if (value) guard around Wh_FreeStringSetting are redundant. This is a fine helper as-is, but WindhawkUtils::StringSetting (RAII) would remove the manual free entirely.

Functionality notes

Non-critical observations about the feature behavior itself.

• Every IconView Loaded triggers a full RestoreLayout + rediscover + reapply synchronously, bypassing the 150 ms ScheduleReapply coalescing you already built for visibility changes. During tray churn (icons appearing/disappearing) this repeats the whole discovery/snapshot/apply pass more often than needed. Routing the IconView-Loaded path through ScheduleReapply() too would coalesce bursts into a single reapply. Not a correctness issue (each pass is idempotent, and it mirrors vd-switcher's approach), just wasted work.
• The experimental Left/Right-of-Start positions re-run PositionStartGroup on every RootGrid LayoutUpdated and write back the repeater margin / Start RenderTransform. The >0.5 px thresholds make it converge, but it does contend with the taskbar's own re-centering (and with other Start-position mods) each layout pass. Already flagged as experimental in the README — just an FYI.