Show configuration keys in UI tooltips - #4968
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughWinUtil now includes configuration keys in application and tweak tooltips. A shared formatter handles blank descriptions. Application entries and generated controls use the formatted tooltips. Tests and automation documentation cover the behavior. ChangesConfiguration tooltips
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant ConfigEntry
participant InvokeWPFUIElements
participant GetWinUtilConfigToolTip
participant WPFControl
ConfigEntry->>InvokeWPFUIElements: Provide description and selectable key
InvokeWPFUIElements->>GetWinUtilConfigToolTip: Format tooltip
GetWinUtilConfigToolTip-->>InvokeWPFUIElements: Return formatted tooltip
InvokeWPFUIElements->>WPFControl: Assign tooltip
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
pester/config-tooltips.Tests.ps1 (1)
32-37: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winCover every generated control in the renderer test.
Line 35 verifies the computed tooltip property, but it does not verify the six assignments at Lines 194, 228, 272, 402, 453, and 495. A regression in one control type can pass this test. Add one assertion for each assignment, or render the controls and inspect their
ToolTipvalues.The PR objective covers all generated control types, so the test should cover each changed assignment.
Suggested focused assertions
$rendererScript | Should -Match 'ToolTip\s*= Get-WinUtilConfigToolTip -Description \$entryInfo\.description -ConfigKey \$entry' $rendererScript | Should -Not -Match '\.ToolTip = \$entryInfo\.Description' + $rendererScript | Should -Match '\$toggleButton\.ToolTip = \$entryInfo\.ToolTip' + $rendererScript | Should -Match '\$button\.ToolTip = \$entryInfo\.ToolTip' + $rendererScript | Should -Match '\$radioButton\.ToolTip = \$entryInfo\.ToolTip' + $rendererScript | Should -Match '\$checkBox\.ToolTip = \$entryInfo\.ToolTip' + ([regex]::Matches($rendererScript, '\$label\.ToolTip = \$entryInfo\.ToolTip')).Count | + Should -Be 2🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@pester/config-tooltips.Tests.ps1` around lines 32 - 37, Expand the test in “uses configuration-key tooltips for generated tweak controls” to verify tooltip assignment for every generated control type, covering each of the six renderer assignments referenced in Invoke-WPFUIElements.ps1. Add focused assertions for each assignment or render controls and inspect their ToolTip values, while retaining the existing computed-tooltip assertion.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@pester/config-tooltips.Tests.ps1`:
- Around line 32-37: Expand the test in “uses configuration-key tooltips for
generated tweak controls” to verify tooltip assignment for every generated
control type, covering each of the six renderer assignments referenced in
Invoke-WPFUIElements.ps1. Add focused assertions for each assignment or render
controls and inspect their ToolTip values, while retaining the existing
computed-tooltip assertion.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 995dec37-4ea7-404f-86bb-41a2428f8eb3
📒 Files selected for processing (5)
docs/src/content/docs/guides/automation.mdxfunctions/private/Get-WinUtilConfigToolTip.ps1functions/private/Initialize-InstallAppEntry.ps1functions/public/Invoke-WPFUIElements.ps1pester/config-tooltips.Tests.ps1
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f9db6f5208
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Checked = $entryInfo.Checked | ||
| ButtonWidth = $entryInfo.ButtonWidth | ||
| GroupName = $entryInfo.GroupName # Added for RadioButton groupings | ||
| ToolTip = Get-WinUtilConfigToolTip -Description $entryInfo.description -ConfigKey $entry |
There was a problem hiding this comment.
Limit configuration tooltips to importable keys
When a user follows the new automation guide and copies the advertised key from a generated but non-selectable control—such as WPFchangedns, WPFOOSUbutton, or WPFFixesNTPPool—this unconditional tooltip labels the identifier as a usable configuration key. However, functions/private/Update-WinUtilSelections.ps1:4-12 recognizes only the install, tweak, toggle, feature, and AppX prefixes, then calls Add through a null list name for unmatched identifiers, so importing a file containing one of these advertised keys fails. Restrict these tooltips to entries that the import/export format supports, or extend that format to represent these controls.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Addressed in 3aa72d6. Generated tooltips now add a configuration key only when the control is selectable and its prefix is handled by Update-WinUtilSelections. Buttons, combo boxes, radio buttons, and notes retain their existing description behavior and no longer advertise non-importable identifiers. I also expanded the focused assertions and reran all 557 Pester tests plus Compile.ps1 successfully.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@functions/public/Invoke-WPFUIElements.ps1`:
- Around line 69-73: Update the tooltip-selection logic around
$isSelectableEntry in Invoke-WPFUIElements so every supported importable control
type, including ComboBox, RadioButton, and Button, receives the formatted
tooltip from Get-WinUtilConfigToolTip via $entryInfo.ToolTip. Extend the
predicate beyond empty, Toggle, and ToggleButton types, and replace the affected
direct $entryInfo.Description uses at the referenced control branches.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: ff1dedee-47ba-4235-b828-cc34d0c93cde
📒 Files selected for processing (2)
functions/public/Invoke-WPFUIElements.ps1pester/config-tooltips.Tests.ps1
🚧 Files skipped from review as they are similar to previous changes (1)
- pester/config-tooltips.Tests.ps1
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3aa72d6d9d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| $entryInfo = $configHashtable[$entry] | ||
| $entryToolTip = $entryInfo.description | ||
| $isSelectableEntry = [string]::IsNullOrWhiteSpace([string]$entryInfo.type) -or $entryInfo.type -in @("Toggle", "ToggleButton") | ||
| $isImportableKey = $entry -match '^(WPFTweaks|WPFToggle|WPFFeature|WPFAppx)' |
There was a problem hiding this comment.
Do not advertise toggle keys for headless configs
When a user adds an advertised WPFToggle* key to a configuration and launches the documented -Config workflow, Update-WinUtilSelections stores it only in selectedToggles, but the scripts/main.ps1 config path calls Invoke-WinUtilAutoRun, which processes only tweaks, features, apps, and AppX entries. Because this headless path never creates the form whose Checked handlers apply toggles, the key is silently ignored; exclude WPFToggle here or add toggle handling to the automation path.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Addressed in 8b1c15c. WPFToggle entries are now excluded from advertised configuration keys because Invoke-WinUtilAutoRun does not process selectedToggles in the documented headless -Config path. The tooltip is now limited to checkbox selections that automation actually consumes, and the focused test locks in that exclusion. All 557 tests and Compile.ps1 pass.
What changed
Why
Users editing exported configuration files currently need to search the source JSON to discover identifiers such as
WPFInstallfirefoxandWPFTweaksTelemetry. Exposing the identifier alongside the existing description keeps that information available in the UI without changing the configuration format or interaction model.Closes #4921.
Validation
Invoke-Pester -Path 'pester/*.Tests.ps1' -Output Normal -CI— 557 passed./Compile.ps1— passed