Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughRemoved an initial transparent navigation-bar setting; replaced multiple semi-transparent black-theme whites with opaque values; normalized several component alpha/transparency usages; changed app category/icon fallback colors and gradients to use ColorScheme.surface; added a theme-aware post-frame navigation-bar color setter; deleted OSSAR and translations GitHub Actions workflows. Changes
Sequence Diagram(s)sequenceDiagram
participant Widget as Updatium Widget
participant Settings as SettingsProvider
participant Media as MediaQuery
participant Scheduler as SchedulerBinding
participant System as SystemChrome
Widget->>Settings: read theme setting (nullable)
Widget->>Media: read platformBrightness
Widget->>Scheduler: addPostFrameCallback(callback)
Scheduler->>System: callback invokes setSystemUIOverlayStyle(color based on theme/brightness)
System-->>Widget: navigation bar color applied
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request focuses on resolving an opacity-related bug and improving UI consistency by replacing hardcoded transparent colors with theme-based surface colors. This ensures that the application's appearance adapts correctly to different themes and avoids unexpected visual artifacts. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
lib/pages/apps.dart (1)
160-171:⚠️ Potential issue | 🟡 MinorFallback color ignores the
alphaparameter.When no category color is set, the function returns
Theme.of(context).colorScheme.surfacedirectly without applying thealphaparameter, whereas the existing-category path (line 167) applies.withAlpha(alpha). This inconsistency may cause visual differences when categories are missing colors.🛠️ Proposed fix to apply alpha consistently
Color getCategoryColor( String category, int alpha, SettingsProvider settingsProvider, ) { final categoryColorValue = settingsProvider.categories[category]; if (categoryColorValue != null) { return Color(categoryColorValue).withAlpha(alpha); } // Fallback to theme-based surface color - return Theme.of(context).colorScheme.surface; + return Theme.of(context).colorScheme.surface.withAlpha(alpha); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/pages/apps.dart` around lines 160 - 171, The fallback in getCategoryColor currently returns Theme.of(context).colorScheme.surface without applying the alpha; update the fallback to apply the same alpha as the existing-category path by calling .withAlpha(alpha) on the Theme color (use the same pattern as when categoryColorValue != null). Locate getCategoryColor and replace the final return to return Theme.of(context).colorScheme.surface.withAlpha(alpha) so both branches consistently respect the alpha parameter from settingsProvider/categoryColorValue.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@lib/main.dart`:
- Around line 889-891: Inside createTheme, the trackOutlineColor property is
incorrectly calling Theme.of(context).colorScheme which picks up the parent
theme; replace that call to use the local scheme parameter instead (i.e. return
scheme.outline) inside the WidgetStateProperty.resolveWith block for
trackOutlineColor so the switch outline uses the color scheme being constructed
by createTheme.
- Around line 156-161: The SystemUiOverlayStyle is hardcoded to Colors.white
causing a white nav bar in dark mode; update the DeviceInfoPlugin/android SDK
>=29 branch to set the navigation bar color to a theme-aware or transparent
value instead of Colors.white—use the app's current theme brightness (via
Theme.of(context).brightness or a passed-in ThemeData) to choose
Colors.transparent or a color derived from
ThemeData.navigationBarTheme/backgroundColor, and call
SystemChrome.setSystemUIOverlayStyle(SystemUiOverlayStyle(...)) with that
computed color while keeping
SystemChrome.setEnabledSystemUIMode(SystemUiMode.edgeToEdge) unchanged; locate
the change around DeviceInfoPlugin().androidInfo,
SystemChrome.setSystemUIOverlayStyle, and SystemUiOverlayStyle to implement this
fix.
---
Outside diff comments:
In `@lib/pages/apps.dart`:
- Around line 160-171: The fallback in getCategoryColor currently returns
Theme.of(context).colorScheme.surface without applying the alpha; update the
fallback to apply the same alpha as the existing-category path by calling
.withAlpha(alpha) on the Theme color (use the same pattern as when
categoryColorValue != null). Locate getCategoryColor and replace the final
return to return Theme.of(context).colorScheme.surface.withAlpha(alpha) so both
branches consistently respect the alpha parameter from
settingsProvider/categoryColorValue.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 0b384ba4-d8ce-42bf-bb23-9225483e7d51
📒 Files selected for processing (2)
lib/main.dartlib/pages/apps.dart
|
Warning Gemini encountered an error creating the review. You can try again by commenting |
There was a problem hiding this comment.
♻️ Duplicate comments (1)
lib/main.dart (1)
894-903:⚠️ Potential issue | 🟠 MajorResolve the nav bar color from the effective app theme, not
Theme.of(context).This callback runs above the
MaterialAppcreated below, soTheme.of(context)here reads the ancestor/fallback theme rather than the theme built fromlightColorScheme/darkColorScheme. In dark or system mode that can still produce the wrong navigation bar color, and the hardcoded black/white pair also skips your dynamic/seeded surface colors.🛠️ Proposed fix
// Set theme-aware system UI overlay style for Android 10+ WidgetsBinding.instance.addPostFrameCallback((_) { - final brightness = Theme.of(context).brightness; - final systemNavigationBarColor = brightness == Brightness.dark - ? Colors.black - : Colors.white; + final platformBrightness = + WidgetsBinding.instance.platformDispatcher.platformBrightness; + final useDarkTheme = + settingsProvider.theme == ThemeSettings.dark || + (settingsProvider.theme == ThemeSettings.system && + platformBrightness == Brightness.dark); + final systemNavigationBarColor = + useDarkTheme + ? darkColorScheme.surface + : lightColorScheme.surface; SystemChrome.setSystemUIOverlayStyle( - SystemUiOverlayStyle(systemNavigationBarColor: systemNavigationBarColor), + SystemUiOverlayStyle( + systemNavigationBarColor: systemNavigationBarColor, + ), ); });In Flutter, if `Theme.of(context)` is called in a widget's `build` method before returning a `MaterialApp`, does it resolve the `MaterialApp` theme being created, or only an ancestor/fallback theme?🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/main.dart` around lines 894 - 903, The post-frame callback that sets SystemChrome UI uses Theme.of(context) before the MaterialApp is built, so it reads only the ancestor fallback theme and also hardcodes black/white instead of using the app color scheme; move the WidgetsBinding.instance.addPostFrameCallback block into a context that is inside the MaterialApp (for example the MaterialApp.builder or a child widget) so Theme.of(context) resolves the effective app theme, and compute systemNavigationBarColor from the active ThemeData.colorScheme (e.g. colorScheme.surface or another appropriate surface/seeded color) before calling SystemChrome.setSystemUIOverlayStyle to apply the correct themed navigation bar color.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@lib/main.dart`:
- Around line 894-903: The post-frame callback that sets SystemChrome UI uses
Theme.of(context) before the MaterialApp is built, so it reads only the ancestor
fallback theme and also hardcodes black/white instead of using the app color
scheme; move the WidgetsBinding.instance.addPostFrameCallback block into a
context that is inside the MaterialApp (for example the MaterialApp.builder or a
child widget) so Theme.of(context) resolves the effective app theme, and compute
systemNavigationBarColor from the active ThemeData.colorScheme (e.g.
colorScheme.surface or another appropriate surface/seeded color) before calling
SystemChrome.setSystemUIOverlayStyle to apply the correct themed navigation bar
color.
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
lib/main.dart (1)
396-411:⚠️ Potential issue | 🟠 MajorUpdate stale comment and fix Material 3 color semantics for AMOLED black theme.
Line 396 comment states "Apply semi-transparent surface colors" but the code uses fully opaque colors; update the comment to match actual implementation.
More critically, the semantic design is incorrect. According to Material 3 guidelines, surface container variants should be tone-based variations of the surface color (darker in dark themes), not inverse colors. Setting
surfaceContainerHighest,surfaceContainerHigh,surfaceContainer,surfaceContainerLow,surfaceContainerLowest, andsurfaceBrightto pure white whilesurfaceis black violates M3 design patterns and creates accessibility issues—specifically, whiteonSurfacetext on white containers results in zero contrast.For AMOLED black theme, these container variants should use dark gray tones that maintain proper contrast hierarchy with onSurface/onSurfaceVariant colors.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/main.dart` around lines 396 - 411, The comment is stale and the AMOLED black theme violates Material 3 semantics: when settingsProvider.useBlackTheme you set darkColorScheme.surface = Colors.black but then set surfaceContainerHighest/High/Container/Low/Lowest and surfaceBright to pure white and onSurface/onSurfaceVariant to white, causing zero-contrast containers; update the comment to reflect opaque black behavior and replace the white container variants and surfaceBright with darker gray/near-black tones (tone-based, progressively lighter than surface) so they form a proper contrast hierarchy with onSurface/onSurfaceVariant; ensure onSurface remains readable (use light text on dark containers) and adjust outline/outlineVariant if needed to darker greys to preserve M3 semantics for dark themes (refer to darkColorScheme and the listed surfaceContainer* and surfaceBright properties).
🧹 Nitpick comments (1)
lib/main.dart (1)
575-575: Consider whether fully opaque black shadow is intentional.Changing from a semi-transparent shadow (
Colors.black.withValues(alpha: ...)) to fully opaqueColors.blackmay produce harsher shadows than intended for elevated buttons in light mode. If this is intentional for the opacity fix, this is fine; otherwise, consider retaining some transparency.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/main.dart` at line 575, The shadow color was changed to fully opaque Colors.black which may be too harsh; update the shadow color used (the Colors.black reference) to a semi-transparent value like Colors.black.withOpacity(0.12) or use Theme.of(context).shadowColor so shadows remain subtle for ElevatedButton/Elevation-related styles, or add a comment if full opacity is intentional; modify the Colors.black usage accordingly in the widget/theme definition where the shadow color is set (the line currently using Colors.black).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@lib/main.dart`:
- Line 788: The selectionColor is currently set to a fully opaque color
(selectionColor: scheme.primary) which hides selected text; update the
assignment to use a semi-transparent variant of the primary color (e.g.,
scheme.primary.withOpacity(0.30–0.40)) so the highlight is translucent and
selected text remains readable—change the selectionColor usage where it is set
to scheme.primary to use withOpacity (or an equivalent alpha) on scheme.primary.
- Line 868: The overlayColor currently uses a fully opaque scheme.primary which
hides the thumb/track; change the overlayColor assignment to return a
semi-transparent variant of scheme.primary using
MaterialStateProperty.resolveWith (e.g., scheme.primary.withOpacity(0.12) or
withAlpha) so the ripple/overlay is translucent during interaction; update the
code where overlayColor is set (referencing overlayColor and scheme.primary) to
use MaterialStateProperty.resolveWith returning the semi-transparent color for
all states.
- Around line 894-904: The post-frame callback is reading
Theme.of(context).brightness (which uses an ancestor theme) instead of the theme
being constructed; update the callback in
WidgetsBinding.instance.addPostFrameCallback to derive brightness from
settingsProvider.theme (e.g., treat ThemeMode.dark or ThemeMode.system resolved
via platformBrightness if applicable) and compute systemNavigationBarColor from
that value, then call SystemChrome.setSystemUIOverlayStyle as before; replace
references to Theme.of(context).brightness with logic using
settingsProvider.theme so the nav bar color matches the configured
lightColorScheme/darkColorScheme used when building MaterialApp.
---
Outside diff comments:
In `@lib/main.dart`:
- Around line 396-411: The comment is stale and the AMOLED black theme violates
Material 3 semantics: when settingsProvider.useBlackTheme you set
darkColorScheme.surface = Colors.black but then set
surfaceContainerHighest/High/Container/Low/Lowest and surfaceBright to pure
white and onSurface/onSurfaceVariant to white, causing zero-contrast containers;
update the comment to reflect opaque black behavior and replace the white
container variants and surfaceBright with darker gray/near-black tones
(tone-based, progressively lighter than surface) so they form a proper contrast
hierarchy with onSurface/onSurfaceVariant; ensure onSurface remains readable
(use light text on dark containers) and adjust outline/outlineVariant if needed
to darker greys to preserve M3 semantics for dark themes (refer to
darkColorScheme and the listed surfaceContainer* and surfaceBright properties).
---
Nitpick comments:
In `@lib/main.dart`:
- Line 575: The shadow color was changed to fully opaque Colors.black which may
be too harsh; update the shadow color used (the Colors.black reference) to a
semi-transparent value like Colors.black.withOpacity(0.12) or use
Theme.of(context).shadowColor so shadows remain subtle for
ElevatedButton/Elevation-related styles, or add a comment if full opacity is
intentional; modify the Colors.black usage accordingly in the widget/theme
definition where the shadow color is set (the line currently using
Colors.black).
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
lib/main.dart (1)
868-868:⚠️ Potential issue | 🟠 MajorSlider overlay color should be semi-transparent for proper visual feedback.
The
overlayColorprovides visual feedback during interaction (the ripple circle around the thumb). Using a fully opaquescheme.primarywill completely obscure the slider thumb and track during touch interaction, creating a poor user experience.🛡️ Proposed fix to restore transparency
- overlayColor: scheme.primary, + overlayColor: WidgetStatePropertyAll(scheme.primary.withOpacity(0.12)),🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/main.dart` at line 868, Replace the fully opaque overlay color so the slider ripple is semi‑transparent: locate the assignment overlayColor: scheme.primary and change it to use a translucent version of the primary color (e.g. scheme.primary.withOpacity(0.12)); if overlayColor expects a MaterialStateProperty, wrap the translucent color with MaterialStateProperty.all(...). This preserves the original color while restoring proper semi‑transparent interaction feedback.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@lib/main.dart`:
- Around line 759-760: tileColor and selectedTileColor are both set to
scheme.surface, making selected items visually indistinguishable; update the
selectedTileColor (the property named selectedTileColor) to a more contrasting
scheme value (for example scheme.secondaryContainer or
scheme.surfaceContainerHighest) so the selected state is visually distinct from
tileColor (scheme.surface), and ensure any other selection indicators remain
consistent.
- Around line 400-410: The theme sets all surface container levels
(surfaceContainerHighest, surfaceContainerHigh, surfaceContainer,
surfaceContainerLow, surfaceContainerLowest) to Colors.white, removing visual
hierarchy; change these properties to a subtle stepped scale of colors (e.g.,
slightly darker/lighter whites or greys, or the same base color with
increasing/decreasing opacity) so nested/elevated surfaces remain
distinguishable — update the entries for surfaceContainerHighest,
surfaceContainerHigh, surfaceContainer, surfaceContainerLow,
surfaceContainerLowest (and verify surfaceDim/surfaceBright still provide
required contrast) to use incremental shades instead of identical Colors.white.
- Around line 573-575: The shadowColor change makes light mode use fully opaque
Colors.black, producing harsh shadows; update the shadowColor expression (where
shadowColor is set alongside isDark) to use a semi-transparent black for the
light theme (e.g., match the opacity used in dark mode or a slightly stronger
transparent black) instead of Colors.black, so replace Colors.black with a
transparent variant (such as Colors.black38 or Colors.black.withOpacity(...)) in
the shadowColor assignment.
---
Duplicate comments:
In `@lib/main.dart`:
- Line 868: Replace the fully opaque overlay color so the slider ripple is
semi‑transparent: locate the assignment overlayColor: scheme.primary and change
it to use a translucent version of the primary color (e.g.
scheme.primary.withOpacity(0.12)); if overlayColor expects a
MaterialStateProperty, wrap the translucent color with
MaterialStateProperty.all(...). This preserves the original color while
restoring proper semi‑transparent interaction feedback.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: aba98057-0ecc-49bf-8342-a284ec170bc7
📒 Files selected for processing (3)
.github/workflows/ossar.yml.github/workflows/translations.ymllib/main.dart
💤 Files with no reviewable changes (2)
- .github/workflows/translations.yml
- .github/workflows/ossar.yml
omeritzics
changed the title
omeritzics
changed the title
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
🚫 CI Build Failed
The automated build process failed. Please review the build logs and fix the issues before requesting another review.
Next steps:
- Check the build logs for specific errors
- Fix the identified issues
- Push your fixes to this branch
- The CI will automatically re-run
Once the build passes, this review will be dismissed automatically.
github-actions
bot
dismissed
their stale review
✅ CI Build Passed - Automatically dismissing previous rejection as the build now succeeds.
There was a problem hiding this comment.
🚫 CI Build Failed
The automated build process failed. Please review the build logs and fix the issues before requesting another review.
Next steps:
- Check the build logs for specific errors
- Fix the identified issues
- Push your fixes to this branch
- The CI will automatically re-run
Once the build passes, this review will be dismissed automatically.
|
TODO: REVERT TO THE LAST SUCCESSFUL COMMIT It was a horrible idea to work on the code on the wee hours of the night... |
|
Okay, I'll open a new pull request later. |
1 participant
Summary by CodeRabbit
Visual & Theme Improvements
Chores