Skip to content

Use the raised surface token for diff hunk headers - #73

Merged
AhmadKharfan merged 1 commit into
developfrom
fix/diff-hunk-header-token
Jul 29, 2026
Merged

Use the raised surface token for diff hunk headers#73
AhmadKharfan merged 1 commit into
developfrom
fix/diff-hunk-header-token

Conversation

@AhmadKharfan

Copy link
Copy Markdown
Owner

Why

Three MaterialTheme.colorScheme usages remained after the type-scale migration, deliberately left because they had no mapping in Theme.kt's colorScheme(...). I measured what they actually resolve to:

Token Dark Light
surfaceVariant #49454F purple-grey #E7E0EC lavender-tinted
tertiary #EFB8C8 pink #7D5260 rose
secondary #CCC2DC lavender #625B71 purple-grey

These are Material 3's baseline purple palette, rendering inside an app whose direction is "Nordic Clarity × JetBrains" with calm neutrals and an emerald accent. None of it was chosen.

This PR fixes the one whose semantic purpose is unambiguous. The other two need a design decision and are documented below rather than guessed at.

What changed

GitDiffScreen.HunkHeader — the @@ -1,4 +1,6 @@ strip above each diff hunk — now uses AslTheme.colors.surfaceContainerHigh instead of MaterialTheme.colorScheme.surfaceVariant.

The semantic is exact: a hunk header is a raised container strip within a surface, which is precisely what surfaceContainerHigh exists for.

Behavior

Rendering stays consistent, and the visual hierarchy is preserved exactly — the header remains lighter than the surface it sits on:

Surface Header before Header after
Dark #2B2D30 #49454F #35373C
Light #FFFFFF #E7E0EC #E9EAEE

Light mode is effectively identical (#E7E0EC#E9EAEE). Dark mode loses a purple tint it never should have had, moving to the palette's own neutral grey at the same relative weight.

The decision still needed — git graph lane colours

GitHistoryScreen.GitGraphGutter builds a categorical palette indexed by palette[lane % 6] to tell branch lanes apart. It carries no semantic meaning; the colours only need to be distinguishable. It is currently assembled from three different sources:

colors.accentPrimary       // Asl token — CHANGES with the user's accent setting
MaterialTheme.colorScheme.tertiary    // M3 stock pink
MaterialTheme.colorScheme.secondary   // M3 stock lavender
colors.error               // Asl token that means "error"
Color(0xFF43A047)          // hardcoded green, identical in light and dark
Color(0xFFFF8F00)          // hardcoded amber, identical in light and dark

Four separate problems, only one of which is the MaterialTheme usage:

  1. Lane collisions that depend on a user setting. Lane 0 follows the chosen accent. Measured RGB distances against the nearest other lane: Amber accent → distance 60 from lane 5's #FF8F00; Emerald → 98 from lane 4's #43A047. Below roughly 80 these are not distinguishable on a 10dp lane, so an Amber user sees two lanes that look the same.
  2. error red used as a lane colour — semantically misleading; red means failure everywhere else in this app.
  3. Two hardcoded literals that do not adapt between light and dark.
  4. M3 pink and lavender that belong to no palette this app uses.

Why this is not fixed here: there is no existing token for a qualitative palette — every colour in AslColorScheme is semantic (error, warning, success, info, accentPrimary). Creating one means choosing six colours, which changes rendering by definition. Baking the current six in as a token would preserve the collisions and the unintended pink.

The decision required: add AslColorScheme.graphLanes: List<Color> — six qualitative colours defined per light and dark scheme, chosen to be mutually distinguishable at 10dp and to avoid the semantic colours so error red never reads as a branch.

A reasonable starting point already exists in the palette: the syntax colours are seven designed, distinguishable, light/dark-aware hues tuned for this app (syntaxType #4EC9B0, syntaxNumber #6897BB, syntaxKeyword #CC7832, syntaxString #6A8759, syntaxFunction #FFC66D, syntaxVariable #A9B7C6). Whether to reuse those hues or commission a dedicated ramp is a design call, not a refactor.

Until then GitHistoryScreen keeps its MaterialTheme import, and its two baseline entries stay — visible rather than silently papered over.

Verification

  • ./gradlew test — all modules pass.
  • ./gradlew :app:compileDebugKotlin — passes.
  • ./gradlew detekt — passes.
  • M3 default values measured directly via lightColorScheme() / darkColorScheme() rather than recalled.
  • Only two files still import MaterialTheme: Theme.kt (the adapter that installs the tokens) and GitHistoryScreen.kt (the undecided lane palette).

Baseline

feature/git/detekt-baseline.xml regenerated — 1 removed, 0 added (ForbiddenImport:GitDiffScreen.kt). Project total 242 → 241.

@AhmadKharfan
AhmadKharfan merged commit 204aa03 into develop Jul 29, 2026
2 checks passed
@AhmadKharfan
AhmadKharfan deleted the fix/diff-hunk-header-token branch July 29, 2026 18:42
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