[chaochenzhudian]

Summary

Updates Floating Taskbar to 2.1.14 with fixes for taskbar and tray hover cards that expose CornerRadius directly on their owning Control, rather than through a named BackgroundElement or BackgroundBorder.

Changes

• Add Control support to hover-radius get, set, property-change tracking, and restore paths.
• Treat the following direct hover hosts as hover cards:
  • SystemTray.ChevronIconView
  • SystemTray.IconView
  • SystemTray.NotifyIconView
  • SystemTray.OmniButton
  • SystemTray.SystemTrayFrame
• Keep direct controls from receiving the named-background vertical layout and tray-box sizing overrides.
• Lower the default taskbar hover radius from 20 to 10 physical pixels.

Validation

• .github/pr_validation.py passes with no warnings.
• Local Windhawk 1.7.3 builds pass for x86_64 and aarch64.
• The update is based on the merged 2.1.13 source, so the previous review fixes and multi-monitor improvements are retained.

Changelog

If this pull request updates an existing mod, describe the changes inside the changelog markers:

• Add hover-radius support for taskbar and tray controls that expose CornerRadius directly.
• Cover SystemTray icon, notification icon, quick-settings, and tray-frame hover hosts.
• Lower the default hover corner radius from 20 to 10 pixels.

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): OpenAI Codex
• • 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.

The submitter supplied the bug fixes. OpenAI Codex merged those changes onto the current 2.1.13 source, ran validation, and prepared this pull request.

[chaochenzhudian]

/ai-review

[windhawk-reviewer]

Thanks for the pull request! This repository uses a two-stage review: an AI review that you run yourself, followed by a human review.

To get started, comment /ai-review. Once you're happy with the result, comment /ready-for-reviewer to hand it over to a human reviewer.

See the pull request review process for the full details.

[windhawk-reviewer]

Submission review

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

Remember: The AI reviewer can be wrong - it may misread code, flag correct code as broken, or suggest changes that make things worse. Treat its findings as suggestions to verify, not instructions to follow blindly. You're responsible for the code you submit, so if a finding doesn't hold up, say so instead of changing working code to satisfy it.

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

---

No blocking issues — looks good to merge. The change stays inside the hover-radius code. The new Control kind is handled everywhere the other kinds are: get, set, the change callback and restore. The five tray classes skip the vertical layout and tray box sizing meant for the named background elements. try_as<Control>() is now checked first, but in every merged mod that targets BackgroundElement/BackgroundBorder, that element is a Border. So the new order doesn't change how the existing named elements are handled.

Optional improvements

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

• IsHoverBackgroundElement runs twice per element (lines 1849–1850): IsHoverShapeTarget already calls it, and the next line calls it again for namedBackground. Also, the class-name check runs on every element of the taskbar tree too, although all five classes are tray classes. Doing the name check once and the class check only in the tray is simpler, and IsHoverShapeTarget is then no longer needed:

  const bool namedBackground = IsHoverBackgroundElement(root);
  if (namedBackground || (trayContext && IsDirectHoverShapeHost(root))) {

• Screenshot caption (line 23), carried over from the last round: it still says "with the default gradient background", but the default backgroundStyle is system.

Functionality notes

Non-critical observations and ideas about the feature behavior itself.

• SystemTray.SystemTrayFrame is the whole tray, not a hover card (line 1259): it's the same element FindSiblingTray returns (lines 2432–2433). So line 3359 now gives the tray container itself the hover radius, plus a callback that keeps it there. If its template doesn't use CornerRadius, this does nothing. If it does, the whole tray block gets the hover corners. If you saw a highlight that only this entry fixes, a short comment naming the Windows build would help. Otherwise, it can be dropped from the list.
• The change callback uses one radius for all monitors (line 1908): g_hoverRadiusDip holds the value computed for the taskbar applied last (line 3356). On a mixed-DPI setup, when Explorer resets a highlight radius on another monitor's taskbar, the callback gives it the other monitor's DIP value until the next full apply. The new tray controls use this callback too, and secondary taskbars have their own clock and notification buttons. Computing the target from the element's own scale avoids this:

  double target = g_hoverRadiusDip.load();
  if (auto xamlRoot = element.XamlRoot()) {
      if (double scale = xamlRoot.RasterizationScale(); scale > 0) {
          target = g_settingHoverCornerRadius.load() / scale;
      }
  }

• Restore leaves a local value on the tray controls (lines 1832–1833): this was noted in earlier rounds, and it matters more now. A Control normally gets its CornerRadius from its style. Restore writes the saved value back as a local value, so after the mod is disabled, those buttons ignore any later style change from Explorer or another mod until they're recreated. Fix: record whether a local value existed, and clear the property if it didn't:

  // When saving (line 1889):
  saved.hadLocalRadius =
      root.ReadLocalValue(property) != DependencyProperty::UnsetValue();
  // When restoring:
  if (saved.hadLocalRadius) {
      SetHoverShapeRadius(element, saved.kind, saved.cornerRadius);
  } else {
      element.ClearValue(property);
  }

  A TemplateBinding reads as null or as a binding expression, not as unset, so the inner Border#BackgroundBorder elements keep today's behavior. Taskbar Styler handles the same cases in ReadLocalValueWithWorkaround and clears unset values on restore.
• New tray icons get the radius only at the next full apply: this is the same gap as the task-button note from earlier rounds. ApplyHoverShapesRecursive runs only from ApplyToFrame (lines 3357–3360), and NeedsTaskbarReapply (lines 3515–3679) doesn't check hover shapes. As far as I can tell, a tray icon added after the taskbar was styled (an app started later) keeps its default corners until a settings change or a taskbar rebuild. One way to cover it: run ApplyHoverShapesRecursive on the tray again when its width changes, from a SizeChanged handler on the tray frame (the tray grows with each icon).
• No value leaves the hover radius alone (lines 107–114): 0 means square corners, so the mod always replaces the highlight corners, now on the five tray controls as well. Its callback also puts its own value back whenever something else changes it, so a Taskbar Styler theme that rounds these highlights loses its value. The README's compatibility paragraph (lines 49–56) names only RootGrid and BackgroundFill. Mentioning the hover corners there, or making a negative value mean "leave unchanged", would make this clear.

Code overview

For the maintainer: a map of the mod and what it touches outside its own process. Descriptive only — anything that needs a change is listed above. Line numbers refer to the mod source at commit 260d02d. 🟢 added / 🟡 updated / ⚪ unchanged, compared to the currently merged version.

Code regions

• 🟡 Line 1–15: Metadata (targets explorer.exe, ShellHost.exe, ShellExperienceHost.exe; architecture x86-64). Only the version changes, to 2.1.14.
• ⚪ Line 17–71: README with a screenshot, compatibility notes and a Chinese section.
• 🟡 Line 73–199: Settings with zh-CN variants (floatingBar.* geometry; taskbarBackgroundBrush.* style, colors, gradient and custom XAML). The hoverCornerRadius default goes from 20 to 10.
• 🟡 Line 201–471: Includes; settings atomics (hover radius defaults now 10 px / 8 DIP); HookScope call counter; saved-state structs; HoverShapeKind (new Control value); the [[clang::no_destroy]] std::optional record vector; Quick Settings thread globals; host-kind detection.
• ⚪ Line 473–712: Window property names, and the SetWindowPos/MoveWindow hooks. In Explorer they force the taskbar window to the configured area height. In ShellHost.exe, SetWindowPos moves the Quick Settings panel to the published right edge.
• ⚪ Line 714–853: Settings loading and XAML tree helpers.
• 🟡 Line 855–1096: Hover radius get/set (new Control case). Tooltip corner radius: placement, attached and open tooltips, Opened handler, per-thread restore (unchanged). The radius property for each kind (new Control::CornerRadiusProperty).
• ⚪ Line 1098–1246: Tray hover box layout locks, and the name check for BackgroundElement/BackgroundBorder.
• 🟢 Line 1248–1268: IsDirectHoverShapeHost (matches the classes SystemTray.ChevronIconView, IconView, NotifyIconView, OmniButton, SystemTrayFrame) and IsHoverShapeTarget.
• ⚪ Line 1270–1838: Multi-window highlight hiding (accessible-name parsing, ElementPrepared on TaskbarFrameRepeater), vertical layout lock and centering, hover shape restore.
• 🟡 Line 1840–1957: ApplyHoverShapesRecursive. Picks the kind (Control first), registers the radius change callback, sets the radius, and now applies the vertical layout and tray box sizing only to the named background elements.
• ⚪ Line 1959–2759: Background rectangle discovery, color parsing, brush creation (XamlReader::Load for custom XAML), geometry helpers, Quick Settings repositioning and its WinEvent thread.
• ⚪ Line 2761–3749: Click-through window region, RestoreFrame, ApplyToFrame, the per-button refresh, NeedsTaskbarReapply and the 500 ms throttle.
• ⚪ Line 3751–4115: XamlRoot from TaskbarHost: decodes the x64 and ARM64 FrameHeight code and bails out when neither matches. Also HWND ↔ XamlRoot matching, direct apply, the 600 ms calibration timer queue, and the taskbar.dll SYMBOL_HOOK array (address resolution only).
• ⚪ Line 4117–4417: TaskbarFrame hooks (MeasureOverride, OnApplyTemplate, OnLoaded, OnPointerMoved), the tooltip placement and UpdateFrameHeight hooks, the Taskbar.View.dll/ExplorerExtensions.dll SYMBOL_HOOK array, and the kernelbase LoadLibraryExW hook for late-loaded modules.
• ⚪ Line 4419–4744: Taskbar window enumeration (filtered to the current process), relayout kicks, RunFromWindowThread, the tray context menu hook with the SystemTray.dll SYMBOL_HOOK array, and apply, reapply, restore and release on the taskbar thread.
• ⚪ Line 4746–4873: Wh_ModInit (ShellHost.exe gets only the SetWindowPos hook), Wh_ModAfterInit, Wh_ModSettingsChanged (restore, then reapply), Wh_ModBeforeUninit (restore, release state, stop and join the hook thread), Wh_ModUninit (waits for the hook call counter).

Side effects of interest

• ⚪ Line 2580–2583: IPC: Explorer writes the window properties FloatingTaskbarControlCenterTargetRight and FloatingTaskbarControlCenterPillWidth on ShellHost.exe's ControlCenterWindow. ShellHost.exe reads them in its SetWindowPos hook (lines 617–618, 647–648). They are written from ApplyToFrame, the MeasureOverride path (400 ms throttle), the WinEvent callback, Wh_ModAfterInit and settings changes, and are never removed.
• ⚪ Line 2595–2597: IPC: an asynchronous cross-process SetWindowPos that moves ControlCenterWindow, with the same triggers.
• ⚪ Line 2699–2753: Other reach outside the process: SetWinEventHook(EVENT_OBJECT_LOCATIONCHANGE, …, WINEVENT_OUTOFCONTEXT) for all processes, on a mod thread created in Wh_ModAfterInit and joined in Wh_ModBeforeUninit.
• ⚪ Line 2507–2528, 2630, 2656: Other reach outside the process: EnumWindows/FindWindowW over all processes' windows to find taskbar and ControlCenterWindow windows by class. In ShellHost.exe, the hook at lines 649–666 uses this to read the rectangle and DPI of Explorer's taskbar window.

This PR adds no new side effects. There's no file, registry, network or system-settings access. The window region, the WM_SETTINGCHANGE/0x452 messages and the WH_CALLWNDPROC hook all target Explorer's own windows and threads.

---

Next steps:

• /ai-review - after pushing fixes, to get a review of the updated code. You can repeat this as many times as you need, but each review is thorough and usually there's no need for more than 2-3 iterations.
• /ready-for-reviewer - once you're satisfied with the state of the pull request, to hand it over to a human reviewer. If some findings above are left unaddressed, add a short note explaining why.

See the review process for details.

Important: Each reply that was generated by AI must be disclosed by including the following text in the reply: "Generated by AI. Model: (ai-model-name)".

[chaochenzhudian]

/ai-review

[windhawk-reviewer]

Submission review

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

Remember: The AI reviewer can be wrong - it may misread code, flag correct code as broken, or suggest changes that make things worse. Treat its findings as suggestions to verify, not instructions to follow blindly. You're responsible for the code you submit, so if a finding doesn't hold up, say so instead of changing working code to satisfy it.

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

---

No blocking issues — looks good to merge. The mod hasn't changed since the last round: the only new commit merges upstream main, and mods/floating-taskbar.wh.cpp is identical to the version reviewed then. So the notes below are carried over. One snippet (the restore fix) is corrected so that it compiles where it's placed. If you don't plan to act on the optional items, you can hand the PR over with /ready-for-reviewer.

Optional improvements

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

• IsHoverBackgroundElement runs twice per element (lines 1849–1850): IsHoverShapeTarget already calls it, and the next line calls it again for namedBackground. Also, the class-name check runs on every element of the taskbar tree too, although all five classes are tray classes. Doing the name check once and the class check only in the tray is simpler, and IsHoverShapeTarget is then no longer needed:

  const bool namedBackground = IsHoverBackgroundElement(root);
  if (namedBackground || (trayContext && IsDirectHoverShapeHost(root))) {

• Screenshot caption (line 23): it still says "with the default gradient background", but the default backgroundStyle is system.

Functionality notes

Non-critical observations and ideas about the feature behavior itself.

• SystemTray.SystemTrayFrame is the whole tray, not a hover card (line 1259): it's the same element FindSiblingTray returns (lines 2432–2433). So line 3359 gives the tray container itself the hover radius, plus a callback that keeps it there. If its template doesn't use CornerRadius, this does nothing. If it does, the whole tray block gets the hover corners. If you saw a highlight that only this entry fixes, a short comment naming the Windows build would help. Otherwise, it can be dropped from the list.
• The change callback uses one radius for all monitors (line 1908): g_hoverRadiusDip holds the value computed for the taskbar applied last (line 3356). On a mixed-DPI setup, when Explorer resets a highlight radius on another monitor's taskbar, the callback gives it the other monitor's DIP value until the next full apply. The new tray controls use this callback too, and secondary taskbars have their own clock and notification buttons. Computing the target from the element's own scale avoids this:

  double target = g_hoverRadiusDip.load();
  if (auto xamlRoot = element.XamlRoot()) {
      if (double scale = xamlRoot.RasterizationScale(); scale > 0) {
          target = g_settingHoverCornerRadius.load() / scale;
      }
  }

• Restore leaves a local value on the tray controls (lines 1832–1833): this was noted in earlier rounds, and it matters more with this change. A Control normally gets its CornerRadius from its style. Restore writes the saved value back as a local value, so after the mod is disabled, those buttons ignore any later style change from Explorer or another mod until they're recreated. Fix: record whether a local value existed, and clear the property if it didn't:

  // In SavedHoverShape:
  bool hadLocalRadius = false;
  
  // When saving, after `property` is looked up (lines 1891–1892):
  saved.hadLocalRadius =
      property &&
      root.ReadLocalValue(property) != DependencyProperty::UnsetValue();
  
  // When restoring, in place of lines 1832–1833 (`property` is already
  // looked up at lines 1826–1827):
  if (!property || saved.hadLocalRadius) {
      SetHoverShapeRadius(element, saved.kind, saved.cornerRadius);
  } else {
      element.ClearValue(property);
  }

  A TemplateBinding reads as null or as a binding expression, not as unset, so the inner Border#BackgroundBorder elements keep today's behavior. Taskbar Styler handles the same cases in ReadLocalValueWithWorkaround and clears unset values on restore.
• New tray icons get the radius only at the next full apply: this is the same gap as the task-button note from earlier rounds. ApplyHoverShapesRecursive runs only from ApplyToFrame (lines 3357–3360), and NeedsTaskbarReapply (lines 3515–3679) doesn't check hover shapes. As far as I can tell, a tray icon added after the taskbar was styled (an app started later) keeps its default corners until a settings change or a taskbar rebuild. One way to cover it: run ApplyHoverShapesRecursive on the tray again when its width changes, from a SizeChanged handler on the tray frame (the tray grows with each icon).
• No value leaves the hover radius alone (lines 107–114): 0 means square corners, so the mod always replaces the highlight corners, now on the five tray controls as well. Its callback also puts its own value back whenever something else changes it, so a Taskbar Styler theme that rounds these highlights loses its value. The README's compatibility paragraph (lines 49–56) names only RootGrid and BackgroundFill. Mentioning the hover corners there, or making a negative value mean "leave unchanged", would make this clear.

Code overview

For the maintainer: a map of the mod and what it touches outside its own process. Descriptive only — anything that needs a change is listed above. Line numbers refer to the mod source at commit 260d02d. 🟢 added / 🟡 updated / ⚪ unchanged, compared to the currently merged version.

Code regions

• 🟡 Line 1–15: Metadata (targets explorer.exe, ShellHost.exe, ShellExperienceHost.exe; architecture x86-64). Only the version changes, to 2.1.14.
• ⚪ Line 17–71: README with a screenshot, compatibility notes and a Chinese section.
• 🟡 Line 73–199: Settings with zh-CN variants (floatingBar.* geometry; taskbarBackgroundBrush.* style, colors, gradient and custom XAML). The hoverCornerRadius default goes from 20 to 10.
• 🟡 Line 201–471: Includes; settings atomics (hover radius defaults now 10 px / 8 DIP); HookScope call counter; saved-state structs; HoverShapeKind (new Control value); the [[clang::no_destroy]] std::optional record vector; Quick Settings thread globals; host-kind detection.
• ⚪ Line 473–712: Window property names, and the SetWindowPos/MoveWindow hooks. In Explorer they force the taskbar window to the configured area height. In ShellHost.exe, SetWindowPos moves the Quick Settings panel to the published right edge.
• ⚪ Line 714–853: Settings loading and XAML tree helpers.
• 🟡 Line 855–1096: Hover radius get/set (new Control case). Tooltip corner radius: placement, attached and open tooltips, Opened handler, per-thread restore (unchanged). The radius property for each kind (new Control::CornerRadiusProperty).
• ⚪ Line 1098–1246: Tray hover box layout locks, and the name check for BackgroundElement/BackgroundBorder.
• 🟢 Line 1248–1268: IsDirectHoverShapeHost (matches the classes SystemTray.ChevronIconView, IconView, NotifyIconView, OmniButton, SystemTrayFrame) and IsHoverShapeTarget.
• ⚪ Line 1270–1838: Multi-window highlight hiding (accessible-name parsing, ElementPrepared on TaskbarFrameRepeater), vertical layout lock and centering, hover shape restore.
• 🟡 Line 1840–1957: ApplyHoverShapesRecursive. Picks the kind (Control first), registers the radius change callback, sets the radius, and now applies the vertical layout and tray box sizing only to the named background elements.
• ⚪ Line 1959–2759: Background rectangle discovery, color parsing, brush creation (XamlReader::Load for custom XAML), geometry helpers, Quick Settings repositioning and its WinEvent thread.
• ⚪ Line 2761–3749: Click-through window region, RestoreFrame, ApplyToFrame, the per-button refresh, NeedsTaskbarReapply and the 500 ms throttle.
• ⚪ Line 3751–4115: XamlRoot from TaskbarHost: decodes the x64 and ARM64 FrameHeight code and bails out when neither matches. Also HWND ↔ XamlRoot matching, direct apply, the 600 ms calibration timer queue, and the taskbar.dll SYMBOL_HOOK array (address resolution only).
• ⚪ Line 4117–4417: TaskbarFrame hooks (MeasureOverride, OnApplyTemplate, OnLoaded, OnPointerMoved), the tooltip placement and UpdateFrameHeight hooks, the Taskbar.View.dll/ExplorerExtensions.dll SYMBOL_HOOK array, and the kernelbase LoadLibraryExW hook for late-loaded modules.
• ⚪ Line 4419–4744: Taskbar window enumeration (filtered to the current process), relayout kicks, RunFromWindowThread, the tray context menu hook with the SystemTray.dll SYMBOL_HOOK array, and apply, reapply, restore and release on the taskbar thread.
• ⚪ Line 4746–4873: Wh_ModInit (ShellHost.exe gets only the SetWindowPos hook), Wh_ModAfterInit, Wh_ModSettingsChanged (restore, then reapply), Wh_ModBeforeUninit (restore, release state, stop and join the hook thread), Wh_ModUninit (waits for the hook call counter).

Side effects of interest

• ⚪ Line 2580–2583: IPC: Explorer writes the window properties FloatingTaskbarControlCenterTargetRight and FloatingTaskbarControlCenterPillWidth on ShellHost.exe's ControlCenterWindow. ShellHost.exe reads them in its SetWindowPos hook (lines 617–618, 647–648). They are written from ApplyToFrame, the MeasureOverride path (400 ms throttle), the WinEvent callback, Wh_ModAfterInit and settings changes, and are never removed.
• ⚪ Line 2595–2597: IPC: an asynchronous cross-process SetWindowPos that moves ControlCenterWindow, with the same triggers.
• ⚪ Line 2699–2753: Other reach outside the process: SetWinEventHook(EVENT_OBJECT_LOCATIONCHANGE, …, WINEVENT_OUTOFCONTEXT) for all processes, on a mod thread created in Wh_ModAfterInit and joined in Wh_ModBeforeUninit.
• ⚪ Line 2507–2528, 2630, 2656: Other reach outside the process: EnumWindows/FindWindowW over all processes' windows to find taskbar and ControlCenterWindow windows by class. In ShellHost.exe, the hook at lines 649–666 uses this to read the rectangle and DPI of Explorer's taskbar window.

This PR adds no new side effects. There's no file, registry, network or system-settings access. The window region, the WM_SETTINGCHANGE/0x452 messages and the WH_CALLWNDPROC hook all target Explorer's own windows and threads.

---

Next steps:

• /ai-review - after pushing fixes, to get a review of the updated code. You can repeat this as many times as you need, but each review is thorough and usually there's no need for more than 2-3 iterations.
• /ready-for-reviewer - once you're satisfied with the state of the pull request, to hand it over to a human reviewer. If some findings above are left unaddressed, add a short note explaining why.

See the review process for details.

Important: Each reply that was generated by AI must be disclosed by including the following text in the reply: "Generated by AI. Model: (ai-model-name)".

[chaochenzhudian]

AI review for the current head 260d02d reports no blocking issues. The pull request changes only mods/floating-taskbar.wh.cpp and is based on the current upstream main. Handing it over for human review; remaining notes are optional/runtime-testing items.

Generated by AI. Model: GPT-5 Codex
/ready-for-reviewer