Skip to content

Conversation

@SimonMarquis
Copy link
Contributor

This makes the :feature:settings behave like any other feature with api/impl split.

This makes the `:feature:settings` behave like any other feature with api/impl split.
@SimonMarquis SimonMarquis requested a review from dturner as a code owner January 16, 2026 14:07
@gemini-code-assist
Copy link

Summary of Changes

Hello @SimonMarquis, 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 significantly enhances the application's modularity and navigation consistency by refactoring the settings feature. It transitions the settings UI from a standalone dialog to a fully integrated Nav3 dialog screen, aligning it with the established API/implementation architecture. This change streamlines how settings are accessed and managed within the application's navigation flow, improving overall code organization and maintainability.

Highlights

  • Modularization of Settings Feature: The settings feature has been refactored to follow the API/implementation split pattern, similar to other features in the application. This introduces a new :feature:settings:api module.
  • Settings as a Nav3 Dialog Screen: The settings UI is now integrated as a Nav3 dialog screen, utilizing the new DialogNavKey interface and DialogSceneStrategy for consistent navigation handling.
  • Navigation System Enhancements: A new DialogNavKey interface has been introduced to mark navigation keys that should behave as dialogs. The NavigationState now includes currentKeyIgnoringDialogs to correctly identify the underlying screen when a dialog is active.
  • Application UI Refactoring: The main NiaApp composable has been refactored into NiaAppContent, removing the previous manual state management for the settings dialog and integrating it with the Nav3 navigation system.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Comment on lines +79 to +82
/**
* Current [NavKey] but ignores [DialogNavKey]s that could be added on top.
*/
val currentKeyIgnoringDialogs: NavKey by derivedStateOf { currentSubStack.last { it !is DialogNavKey } }
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dturner I'm open to suggestions on how to properly support this.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request is a great refactoring of the settings feature. It successfully migrates the settings dialog to a full-fledged feature module with an api/impl split, integrating it cleanly with the Nav3 navigation library as a dialog screen. The introduction of DialogNavKey and currentKeyIgnoringDialogs in the core navigation module is a smart, generic solution for handling dialogs over other screens. The changes are well-structured and follow the existing architecture of the application. I have one minor suggestion regarding code style for consistency.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant