Files
hash-wallet/lib/themes
jwinterm 04203654f1 Rename Flutter project + binary: cake_wallet -> hash_wallet
The big one. Touches 760+ files. Locks in the user's decision to break
import-line compatibility with upstream cake-tech/cake_wallet in exchange
for a binary named hash_wallet on every platform.

Changes:
- pubspec_description.yaml: project name cake_wallet -> hash_wallet
- 762 Dart files: every 'package:cake_wallet/...' import rewritten to
  'package:hash_wallet/...' (lib/, cw_*/lib/, tool/, test/, integration_test/)
- linux/CMakeLists.txt: BINARY_NAME cake_wallet -> hash_wallet
- windows/CMakeLists.txt: project + BINARY_NAME (CakeWallet -> HashWallet)
- windows/runner/Runner.rc: company / file / product strings to Hash Wallet
  + Such Software LLC copyright
- macos/Runner.xcodeproj/project_base.pbxproj: cake_wallet_new.app refs
  -> hash_wallet.app (macOS output bundle name)
- com.suchsoftware.HashWallet.yml (Flatpak): all binary path refs
  cake_wallet -> hash_wallet (e.g. /app/hash_wallet/hash_wallet)
- linux/com.suchsoftware.HashWallet.desktop: Exec=hash_wallet
- scripts/android/copy_monero_deps.sh: CW_DIR target path
- configure_hash_wallet.sh: error message typo (old filename)

INTENTIONALLY UNCHANGED:
- cw_* subpackage names (cw_core, cw_bitcoin, cw_wownero, etc.) — they
  remain as the historical 'cake wallet' naming; renaming them would
  cascade through every sub-package's internal structure
- Method channel name 'com.cake_wallet/native_utils' in iOS/macOS/Android
  AppDelegates and MainActivity — it's a string identifier that has to
  match the Dart side exactly. Renaming requires both-sides change; it's
  internal-only and not user-visible.
- ghcr.io/cake-tech/cake_wallet:debian13-... docker image references in
  build scripts — that's Cake Labs' published image we use as the build
  environment, not ours.

User data directory now follows the new binary name:
  ~/.local/share/hash_wallet/  (was ~/.local/share/cake_wallet/)
  ~/.config/hash_wallet/       (was ~/.config/cake_wallet/)
Existing users on the old name will need migration if any exist.
2026-05-16 11:33:25 -04:00
..
2025-05-25 23:11:45 +03:00

Material 3 Theming System

This directory contains the Material 3 (M3) theming implementation for Cake Wallet. The theming system is now fully based on Material 3 color tokens and patterns, with all custom theme extensions removed for simplicity, maintainability, and compliance with Material Design 3 guidelines.

Directory Structure

lib/themes/
├── core/                # Theme state management and base theme logic
├── theme_classes/       # Light and dark theme data definitions
├── extensions/          # (Optional) Theme extensions for specific widgets/pages
├── utils/               # Utilities for theme management
└── README.md            # This file

Key Features

  • Material 3 color system with semantic color tokens
  • Dynamic color support (when available)
  • MobX-based state management
  • Simplified theme management
  • Consistent design language across the app

Usage

Accessing Theme Colors

final colorScheme = Theme.of(context).colorScheme;
final primaryColor = colorScheme.primary;
final onSurfaceVariant = colorScheme.onSurfaceVariant;

Available Color Tokens

Material 3 provides a comprehensive set of semantic color tokens that adapt to light/dark themes:

  • primary / onPrimary
  • secondary / onSecondary
  • tertiary / onTertiary
  • error / onError
  • background / onBackground
  • surface / onSurface
  • surfaceVariant / onSurfaceVariant
  • outline, outlineVariant
  • ...and more (see Flutter's ColorScheme)

Theme Management

Theme mode state (light/dark/system) and switching is handled via MobX stores in core/. Use the provided store to get/set the current theme mode and listen for changes.

// Example: Getting the current theme mode
final themeStore = ... // Obtain from provider or context
final isDark = themeStore.isDark;

// Example: Switching theme mode
await themeStore.setThemeMode(ThemeMode.dark);

Best Practices

  1. Always use semantic color tokens from ColorScheme instead of hardcoded colors.
  2. Leverage Material 3 components wherever possible for consistency and accessibility.
  3. Use the MobX theme store for all theme-related state and switching.
  4. Test in both light and dark modes to ensure good contrast and appearance.
  5. Keep any theme extensions minimal and focused (if used at all).
  6. Do not reintroduce custom theme extensions unless absolutely necessary and not covered by Material 3.

Adding or Modifying Themes

  • To update theme colors, edit the files in theme_classes/ (e.g., light_theme.dart, dark_theme.dart).
  • To add a new theme variant, create a new file in theme_classes/ and update the MobX store in core/ to support it.
  • For widget-specific theming, prefer using Material 3's built-in tokens. Only use a theme extension if there is no Material 3 equivalent.

Contributing

  • Follow Material 3 color system and accessibility guidelines.
  • Ensure proper contrast ratios for accessibility.
  • Test all changes in both light and dark modes.
  • Update this documentation if you add new color tokens or theme variants.
  • Keep theme files organized and focused.