Skip to content
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

transparent terminal themes #1561

Merged
merged 6 commits into from
Dec 19, 2024
Merged

transparent terminal themes #1561

merged 6 commits into from
Dec 19, 2024

Conversation

sawka
Copy link
Member

@sawka sawka commented Dec 18, 2024

No description provided.

Copy link

coderabbitai bot commented Dec 18, 2024

Walkthrough

The pull request introduces terminal transparency configuration for Wave, enabling users to customize the terminal's background transparency. This feature is implemented across multiple files, adding two new configuration keys: term:theme and term:transparency, with default values of "default-dark" and 0.5, respectively. The changes span documentation, frontend components, type definitions, and configuration files. New theme options are also added, including "One Dark Pro" and "Rose Pine," alongside adjustments to existing theme display orders. The modifications include updates to the TermViewModel class to manage transparency settings, enhancements to the computeTheme function to apply transparency to theme colors, and the introduction of new keybindings for terminal operations. Additionally, relevant constants and fields have been added to various types to support these new configuration options.

Changes

File Change Summary
docs/docs/config.mdx Updated documentation to include new term:theme and term:transparency configuration keys
frontend/app/view/term/term.tsx Added termTransparencyAtom, updated blockBg atom, and modified getSettingsMenuItems() method to include transparency options
frontend/app/view/term/termtheme.ts Modified computeTheme to include the new transparency parameter
frontend/app/view/term/termutil.ts Added applyTransparencyToColor() function and updated computeTheme() to handle transparency
frontend/types/gotypes.d.ts Added optional term:transparency property to MetaType and SettingsType
pkg/waveobj/metaconsts.go Added MetaKey_TermTransparency constant
pkg/waveobj/wtypemeta.go Added TermTransparency field to MetaTSType struct
pkg/wconfig/defaultconfig/termthemes.json Added "One Dark Pro" and "Rose Pine" themes, updated existing theme display orders
pkg/wconfig/metaconsts.go Added ConfigKey_TermTransparency constant
pkg/wconfig/settingsconfig.go Added TermTransparency field to SettingsType struct

Sequence Diagram

sequenceDiagram
    participant User
    participant SettingsMenu
    participant TermViewModel
    participant TerminalView
    participant ComputeTheme

    User->>SettingsMenu: Select Transparency
    SettingsMenu->>TermViewModel: Update termTransparencyAtom
    TermViewModel->>TerminalView: Trigger theme update
    TerminalView->>ComputeTheme: Call with transparency
    ComputeTheme-->>TerminalView: Return themed terminal
    TerminalView->>User: Display updated terminal
Loading

Possibly related PRs

Poem

🐰 A Rabbit's Ode to Terminal Transparency 🌈
Peek through the code, a window so clear,
Transparency dancing, no longer austere.
Themes blend and shimmer, with magical might,
Wave's terminal glows, a configurable delight!
Hop to the settings, adjust with a grin 🎉


🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🧹 Nitpick comments (3)
frontend/app/view/term/termutil.ts (1)

7-10: LGTM: Consider memoizing color transformations

The transparency calculation is correct and uses the type-safe colord library. For performance optimization, consider memoizing frequently used color transformations if they become a bottleneck.

docs/docs/config.mdx (1)

47-48: Document the valid range for term:transparency.

While the documentation clearly states the default value (0.5), it would be helpful to specify the valid range for the transparency value (e.g., 0.0 to 1.0).

 | term:theme                           | string   | preset name of terminal theme to apply by default (default is "default-dark")                                                                                                 |
-| term:transparency                    | float64  | set the background transparency of terminal theme (default 0.5)                                                                                                               |
+| term:transparency                    | float64  | set the background transparency of terminal theme (0.0 = fully opaque, 1.0 = fully transparent, default 0.5)                                                                  |
frontend/app/view/term/term.tsx (1)

487-521: LGTM! Consider type safety improvement.

The transparency menu implementation is well-structured and consistent with other settings. Consider using an enum or const object for transparency values to improve type safety and maintainability.

+const TRANSPARENCY_VALUES = {
+  DEFAULT: null,
+  TRANSPARENT: 0.5,
+  NONE: 0
+} as const;

 transparencySubMenu.push({
     label: "Transparent Background",
     type: "checkbox",
-    checked: transparencyMeta == 0.5,
+    checked: transparencyMeta === TRANSPARENCY_VALUES.TRANSPARENT,
     click: () => {
         RpcApi.SetMetaCommand(TabRpcClient, {
             oref: WOS.makeORef("block", this.blockId),
-            meta: { "term:transparency": 0.5 },
+            meta: { "term:transparency": TRANSPARENCY_VALUES.TRANSPARENT },
         });
     },
 });
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between cc6da28 and 64bca16.

📒 Files selected for processing (10)
  • docs/docs/config.mdx (1 hunks)
  • frontend/app/view/term/term.tsx (7 hunks)
  • frontend/app/view/term/termtheme.ts (1 hunks)
  • frontend/app/view/term/termutil.ts (1 hunks)
  • frontend/types/gotypes.d.ts (2 hunks)
  • pkg/waveobj/metaconsts.go (1 hunks)
  • pkg/waveobj/wtypemeta.go (1 hunks)
  • pkg/wconfig/defaultconfig/termthemes.json (5 hunks)
  • pkg/wconfig/metaconsts.go (1 hunks)
  • pkg/wconfig/settingsconfig.go (1 hunks)
🔇 Additional comments (13)
pkg/wconfig/metaconsts.go (1)

35-35: LGTM: Config key follows conventions

The new configuration key for terminal transparency follows the established naming pattern and is correctly placed within the terminal-related configuration section.

frontend/app/view/term/termtheme.ts (1)

20-21: LGTM: Verify atom subscription behavior

The transparency value is correctly retrieved from the model atom and properly passed to computeTheme.

Let's verify the atom usage pattern:

✅ Verification successful

LGTM: Atom usage pattern is consistent

The transparency atom is used consistently throughout the codebase:

  • Correctly initialized with a default value of 0.5 via useBlockAtom
  • Properly consumed using useAtomValue in the theme computation
  • Appropriately integrated with the config override system
  • Used consistently in both theme computation and terminal background handling
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for consistent atom usage patterns

# Look for other termTransparencyAtom usages
rg 'termTransparencyAtom' -A 2 -B 2

# Check for similar transparency-related atoms
rg -g '*.{ts,tsx}' 'Atom.*[Tt]ransparency'

Length of output: 2835

pkg/waveobj/metaconsts.go (1)

96-96: LGTM! The constant follows the established naming pattern.

The new constant MetaKey_TermTransparency is correctly placed in the terminal-related section and follows the existing naming convention.

pkg/wconfig/defaultconfig/termthemes.json (4)

25-25: Good change: Removed hardcoded transparency from Default Dark theme.

The background color change from semi-transparent (#77) to solid (#000000) aligns well with the new configurable transparency feature.


28-53: LGTM! One Dark Pro theme is well-defined.

The theme includes all required colors and follows the established structure.


156-180: LGTM! Rose Pine theme is well-defined.

The theme includes all required colors and follows the established structure.


56-56: LGTM! Theme display orders are properly sequenced.

The display orders are logically arranged from 1 to 7 without gaps:

  1. Default Dark
  2. One Dark Pro
  3. Dracula
  4. Monokai
  5. Campbell
  6. Warm Yellow
  7. Rose Pine

Also applies to: 82-82, 108-108, 134-134, 158-158

pkg/waveobj/wtypemeta.go (1)

97-97: LGTM! The transparency field is well-defined.

The TermTransparency field is:

  • Using *float64 which appropriately handles optional values
  • Following the established pattern with omitempty tag
  • Documented with the default value
pkg/wconfig/settingsconfig.go (1)

62-62: LGTM! Well-structured field addition.

The TermTransparency field is properly defined as a pointer type with appropriate JSON tags, following the established patterns in the codebase.

frontend/types/gotypes.d.ts (1)

494-494: LGTM! Consistent type definitions.

The TypeScript type definitions are properly aligned with the Go struct, using appropriate types and modifiers.

Also applies to: 644-644

frontend/app/view/term/term.tsx (3)

66-66: LGTM! Well-implemented transparency atom.

The implementation correctly:

  • Uses useBlockAtom for memoization
  • Bounds the transparency value between 0 and 1
  • Provides a sensible default of 0.5

Also applies to: 208-213


786-787: LGTM! Proper integration with terminal configuration.

The transparency value is correctly retrieved and passed to the theme computation, maintaining consistency with the terminal's configuration system.


217-218: Verify computeTheme implementation.

The function now receives transparency as a third parameter. Let's verify the implementation in the imported module.

✅ Verification successful

computeTheme implementation is correctly handling transparency parameter

The function implementation properly:

  • Accepts termTransparency as the third parameter
  • Applies transparency to both background and selectionBackground colors using applyTransparencyToColor
  • Returns a tuple of [theme, bgcolor] as expected by the destructuring pattern
  • Sets theme background to transparent and returns the original (possibly transparency-modified) bgcolor separately
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify computeTheme function signature and implementation
# Test: Search for computeTheme function definition
ast-grep --pattern 'export function computeTheme($_, $_, $_) {
  $$$
}'

Length of output: 73


Script:

#!/bin/bash
# Let's try a broader search for computeTheme function using ripgrep
rg "computeTheme" -A 5

Length of output: 2656


Script:

#!/bin/bash
# Let's examine the full implementation of computeTheme function
cat frontend/app/view/term/termutil.ts

Length of output: 1329

Comment on lines +12 to +30
// returns (theme, bgcolor, transparency (0 - 1.0))
function computeTheme(
fullConfig: FullConfigType,
themeName: string,
termTransparency: number
): [TermThemeType, string] {
let theme: TermThemeType = fullConfig?.termthemes?.[themeName];
if (theme == null) {
theme = fullConfig?.termthemes?.[DefaultTermTheme] || ({} as any);
}
const themeCopy = { ...theme };
if (termTransparency != null && termTransparency > 0) {
if (themeCopy.background) {
themeCopy.background = applyTransparencyToColor(themeCopy.background, termTransparency);
}
if (themeCopy.selectionBackground) {
themeCopy.selectionBackground = applyTransparencyToColor(themeCopy.selectionBackground, termTransparency);
}
}
Copy link

Choose a reason for hiding this comment

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

💡 Codebase verification

Based on the search results from all scripts, I can now provide a final response:

Transparency implementation needs bounds validation

From the code analysis:

  1. Default transparency is set to 0.5 in term.tsx
  2. UI provides options for transparency: null (default), 0.5 (transparent), and 0 (no transparency)
  3. The computeTheme function only checks for termTransparency != null && termTransparency > 0
  4. No upper bound validation or value clamping is implemented

The current implementation could allow transparency values greater than 1.0, which might lead to unexpected behavior. Consider adding validation or clamping to ensure transparency stays within [0, 1.0].

🔗 Analysis chain

LGTM: Verify transparency behavior with extreme values

The transparency application logic is sound, with proper null checks and conditional application. The code correctly handles both background and selection background colors.

Let's verify the theme computation with various transparency values:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Search for transparency value assignments to ensure they're within bounds

# Look for direct assignments of transparency values
rg -g '*.{ts,tsx,js,jsx}' 'termTransparency.*=.*[0-9]' 

# Look for transparency configuration in JSON/YAML files
rg -g '*.{json,yaml,yml}' '"term:transparency":\s*[0-9]'

Length of output: 210


Script:

#!/bin/bash
# Let's search for all usages and assignments of termTransparency to understand its bounds
rg -g '*.{ts,tsx,js,jsx}' 'termTransparency' -B 2 -A 2

# Also search for any transparency-related configuration or validation
rg -g '*.{ts,tsx,js,jsx}' 'transparency.*=|transparency.*>|transparency.*<' -B 2 -A 2

# Look for any transparency-related types or interfaces
ast-grep --pattern 'interface $_ {
  $$$
  transparency
  $$$
}'

Length of output: 6610


Script:

#!/bin/bash
# Let's check the implementation of applyTransparencyToColor to verify how it handles transparency values
ast-grep --pattern 'function applyTransparencyToColor($_) {
  $$$
}'

# Also search for any transparency value validations or clamps
rg -g '*.{ts,tsx}' 'clamp.*transparency|Math\.(min|max).*transparency' -B 2 -A 2

Length of output: 153

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (1)
frontend/app/view/term/term.tsx (1)

492-525: Consider using a constant for the default transparency value.

The transparency menu implementation is solid, but consider extracting the default transparency value (0.5) into a named constant for better maintainability.

+ const DEFAULT_TERM_TRANSPARENCY = 0.5;
  
  transparencySubMenu.push({
      label: "Transparent Background",
      type: "checkbox",
-     checked: transparencyMeta == 0.5,
+     checked: transparencyMeta == DEFAULT_TERM_TRANSPARENCY,
      click: () => {
          RpcApi.SetMetaCommand(TabRpcClient, {
              oref: WOS.makeORef("block", this.blockId),
-             meta: { "term:transparency": 0.5 },
+             meta: { "term:transparency": DEFAULT_TERM_TRANSPARENCY },
          });
      },
  });
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 13f7a10 and 587fda0.

📒 Files selected for processing (2)
  • docs/docs/keybindings.mdx (1 hunks)
  • frontend/app/view/term/term.tsx (8 hunks)
🔇 Additional comments (5)
docs/docs/keybindings.mdx (1)

74-81: LGTM! Terminal keybindings are well documented.

The new terminal keybindings section clearly documents the standard terminal operations (copy, paste, clear) with their respective keyboard shortcuts, maintaining consistency with common terminal conventions.

frontend/app/view/term/term.tsx (4)

208-213: LGTM! Transparency configuration is well implemented.

The transparency configuration is properly implemented with:

  • Bounded values between 0 and 1
  • Default value of 0.5
  • Proper atom setup for reactive updates

217-218: LGTM! Theme computation properly integrates transparency.

The theme computation correctly incorporates the transparency value when calculating background colors.


419-423: LGTM! Terminal clear keybinding is properly implemented.

The Cmd+k keybinding implementation:

  • Correctly prevents default event behavior
  • Properly clears the terminal
  • Matches the documented behavior in keybindings.mdx

791-792: LGTM! Theme updates properly handle transparency changes.

The useEffect hook correctly incorporates transparency changes into theme updates.

@sawka sawka merged commit eff1263 into main Dec 19, 2024
10 checks passed
@sawka sawka deleted the sawka/term-themes-transparent branch December 19, 2024 18:41
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