Add selectable taskbar limits and refine widget settings - #3
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 385bcac386
ℹ️ 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".
| if (resolvedPreference != _taskbarLimitPreference) | ||
| { | ||
| _taskbarLimitPreference = resolvedPreference; | ||
| _taskbarLimitPreferenceStore.Save(resolvedPreference); |
There was a problem hiding this comment.
Preserve the 5h preference until a weekly fallback exists
When a refresh returns no general windows—such as before the user has signed in—ResolvePreference changes the default 5h preference to Weekly even though no weekly window exists, and this block permanently saves that change. A later successful refresh will therefore show the weekly limit instead of restoring the user's 5h default; only persist the fallback when a weekly window is actually available.
AGENTS.md reference: AGENTS.md:L59-L60
Useful? React with 👍 / 👎.
| preference == TaskbarLimitPreference.FiveHour && | ||
| !IsAvailable(snapshot, TaskbarLimitPreference.FiveHour) | ||
| ? TaskbarLimitPreference.Weekly | ||
| : preference; |
There was a problem hiding this comment.
Resolve an unavailable weekly preference
When an account returns only a 5h window, Select falls back from Weekly to that 5h window, but this method leaves the preference as Weekly. Consequently both menus remain checked on “Weekly limit” while the taskbar tooltip and percentage come from the 5h limit; resolve or disable unavailable weekly selections so the displayed selection matches the displayed data.
AGENTS.md reference: AGENTS.md:L59-L60
Useful? React with 👍 / 👎.
| UseShellExecute = true | ||
| }; | ||
|
|
||
| if (Process.Start(startInfo) is null) |
There was a problem hiding this comment.
Handle failures to launch the release page
On systems without a usable HTTP shell association, or where policy blocks launching the browser, Process.Start can throw Win32Exception rather than return null. Both new menu callbacks invoke this method on the dispatcher without catching that exception, and the global dispatcher handler only logs it without setting Handled, so selecting “Check for updates...” can terminate the widget instead of reporting the launch failure.
Useful? React with 👍 / 👎.
Summary
Validation
dotnet build .\CodexUsageWidget.slnx -c Release --no-restoredotnet test .\CodexUsageWidget.slnx -c Release --no-build --no-restore