-
Notifications
You must be signed in to change notification settings - Fork 8k
Use semantic colors in themes #5796
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary of Changes
Hello @miguelsolorio, 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!
I've implemented a foundational change to our theming system by introducing semantic color tokens. This means we're moving away from directly referencing color codes and instead using descriptive names for colors based on their function within the UI. This initial PR establishes the new semantic color definitions, integrates them into our existing theme infrastructure, and updates a couple of core UI components to use this new system. The goal is to make our theming more robust, easier to manage, and more adaptable for future UI development, with further component migrations planned for subsequent pull requests.
Highlights
- Introduction of Semantic Color Tokens: I've introduced a new
SemanticColors
interface and corresponding objects (lightSemanticColors
,darkSemanticColors
,ansiSemanticColors
) insemantic-tokens.ts
. This defines a structured way to refer to colors based on their purpose (e.g.,text.primary
,status.error
) rather than their specific hexadecimal values. - Integration into the Theming System: The
Theme
class and all existing themes (e.g., ANSI, Default, GitHub) have been updated to store and provide these new semantic color definitions. This ensures that all themes now have a consistent, semantically meaningful color palette available. - Migration of UI Components to Semantic Colors: Key UI components, specifically
Footer.tsx
andInputPrompt.tsx
, have been refactored to use the new semantic color tokens. Instead of importingColors
directly, they now importtheme
fromsemantic-colors.ts
and access colors liketheme.text.secondary
ortheme.status.error
. This demonstrates the practical application and benefit of the semantic approach. - Enhanced Custom Theme Support: The
CustomTheme
interface has been enhanced to allow users to define custom themes using the new semantic color structure. ThecreateCustomTheme
function now intelligently maps these semantic definitions to the underlying color properties, and thevalidateCustomTheme
function has been simplified, reflecting the increased flexibility in custom theme definitions.
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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command>
or @gemini-code-assist <command>
. Below is a summary of the supported commands.
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 issue 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 or fill out our survey to provide feedback.
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
-
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. ↩
it('should return a warning if DiffAdded and DiffRemoved are missing', () => { | ||
const legacyTheme: Partial<CustomTheme> = { ...validTheme }; | ||
delete legacyTheme.DiffAdded; | ||
delete legacyTheme.DiffRemoved; | ||
const result = validateCustomTheme(legacyTheme); | ||
expect(result.isValid).toBe(true); | ||
expect(result.warning).toBe('Missing field(s) DiffAdded, DiffRemoved'); | ||
}); | ||
|
||
it('should return a warning if only DiffRemoved is missing', () => { | ||
const legacyTheme: Partial<CustomTheme> = { ...validTheme }; | ||
delete legacyTheme.DiffRemoved; | ||
const result = validateCustomTheme(legacyTheme); | ||
expect(result.isValid).toBe(true); | ||
expect(result.warning).toBe('Missing field(s) DiffRemoved'); | ||
}); | ||
|
||
it('should return isValid: false for a theme with an invalid DiffAdded color', () => { | ||
const invalidTheme = { ...validTheme, DiffAdded: 'invalid' }; | ||
const result = validateCustomTheme(invalidTheme); | ||
expect(result.isValid).toBe(false); | ||
expect(result.error).toBe('Invalid color format for DiffAdded: invalid'); | ||
}); | ||
|
||
it('should return isValid: false for a theme with an invalid DiffRemoved color', () => { | ||
const invalidTheme = { ...validTheme, DiffRemoved: 'invalid' }; | ||
const result = validateCustomTheme(invalidTheme); | ||
expect(result.isValid).toBe(false); | ||
expect(result.error).toBe('Invalid color format for DiffRemoved: invalid'); | ||
}); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We now allow users to set partial custom themes without needing to add all tokens, so these tests are not needed anymore
There was a problem hiding this 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 introduces a valuable refactoring by using semantic color tokens instead of hardcoded color values, which will significantly improve theming capabilities and code maintainability. The implementation is well-structured, with new files for semantic tokens and updates across various components and themes. However, I've identified a critical issue where color validation for custom themes has been removed, potentially leading to runtime errors. Additionally, there's a minor bug in the InputPrompt
component where a conditional color change was lost during the refactoring. Addressing these points will ensure the new theming system is both robust and correct.
…c-color-tokens # Conflicts: # packages/cli/src/ui/components/Footer.tsx
Code Coverage Summary
CLI Package - Full Text Report
Core Package - Full Text Report
For detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice if we could keep showing errors if there are unrecognized properties in themes or if neither the current or previous name for a color token is specified. That will help users stay more of the rails if they use themes and help users understand if we make breaking theme changes in the future.
Hopefully Gemini CLI can one shot that change if you tell it to look at the changes from your pull request and add back in code and tests that got reverted due to this.
Other than that looks great and lets land asap to avoid merge conflict hassles.
I think disagree with this take, in VS Code when settings are not correct there are LSP warnings and it will ignore the incorrect ones. When I was editing a theme for my own personal use, it was really annoying getting an error when I only wanted to change a few colors instead of the entire theme. It also removes settings that don't exist, which i found annoying when I had a typo. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: Jacob Richman <[email protected]>
Co-authored-by: Jacob Richman <[email protected]>
Co-authored-by: Jacob Richman <[email protected]>
Co-authored-by: Jacob Richman <[email protected]>
Co-authored-by: Jacob Richman <[email protected]>
Co-authored-by: Jacob Richman <[email protected]>
Co-authored-by: Jacob Richman <[email protected]>
Co-authored-by: Jacob Richman <[email protected]>
Co-authored-by: Jacob Richman <[email protected]>
Co-authored-by: Jacob Richman <[email protected]>
TLDR
This allows for colors to be used semantically instead of referencing the color codes directly. This only handles the foundation, the rest of the components will need to be updated in follow up PRs.
Dive Deeper
Introduces the following semantic tokens:
Custom themes would be referenced like:
Reviewer Test Plan
Testing Matrix
Linked issues / bugs