JMR-dev/LibreMediaConverter
1
0
Fork 0
Code Issues 16 Pull Requests Actions Packages Projects Releases Wiki Activity

The theme has never been called the way MainActivity calls it #197

New Issue
Closed
opened 2026-09-02 12:46:22 +00:00 by JMR-dev · 0 comments
JMR-dev commented 2026-09-02 12:46:22 +00:00 (Migrated from github.com)
Copy Link
Copy Source

Wave 4, filed from a coverage read on main @ 54ca2dd, 2026-09-02. The shared filter note is on #194.

The theme has never been called the way the app calls it

app/src/main/java/org/libremediaconverter/ui/theme/Theme.kt:42-43

fun LibreMediaConverterTheme(
    darkTheme: Boolean = isSystemInDarkTheme(),
    dynamicColor: Boolean = true,
    content: @Composable () -> Unit,
)

ThemeColorSchemeTest always passes darkTheme explicitly, so the $default bridge is never entered and isSystemInDarkTheme() is never called. LibreMediaConverterTheme reports mi=21, mb=6, cb=12 at method level. Its only default-argument caller is MainActivity.kt:79, which does not execute on the JVM.

So the app's actual call — no arguments at all — is the one shape nothing exercises.

This is not #68

#68 is about the two unreachable arms, DarkColorScheme and LightColorScheme, which cannot be reached because dynamicColor is always true and nothing can flip it. That is a product decision and it stays open.

This ticket is the reachable half: whether the theme follows the system's dark-mode setting when asked with defaults. The two do not overlap, and closing this one does not close that one.

The work

Two @Config(qualifiers = ...) classes — "" and "+night" — each calling LibreMediaConverterTheme { } bare and reading MaterialTheme.colorScheme from inside the content lambda, asserting the two differ in the direction the qualifier names (background luminance is the readable signal). This is the multi-@Config pattern ForegroundTypeRegimeTest established for the same reason: app/src/test/resources/robolectric.properties pins the suite to one configuration, so a per-class @Config is how a second regime gets exercised at all.

Note that #68's own text already recommends this shape ("Robolectric plus createDrainedComposeRule() can assert the resolved scheme differs across darkTheme/dynamicColor"), for the arms that survive whichever way #68 is decided.

Acceptance: the mutation that must go red

Change the default to darkTheme: Boolean = false. The +night test must fail. Restore, confirm green.

Not in scope

Theme.kt:46's remaining mb=4, cb=2 is Compose recomposition-skip scaffolding — the "do not chase the branch number" case docs/coverage-read-findings.md states for the screens. Leave it.

_Wave 4, filed from a coverage read on `main` @ `54ca2dd`, 2026-09-02. The shared filter note is on #194._ ## The theme has never been called the way the app calls it ``` app/src/main/java/org/libremediaconverter/ui/theme/Theme.kt:42-43 ``` ```kotlin fun LibreMediaConverterTheme( darkTheme: Boolean = isSystemInDarkTheme(), dynamicColor: Boolean = true, content: @Composable () -> Unit, ) ``` `ThemeColorSchemeTest` always passes `darkTheme` explicitly, so the `$default` bridge is never entered and **`isSystemInDarkTheme()` is never called**. `LibreMediaConverterTheme` reports `mi=21, mb=6, cb=12` at method level. Its only default-argument caller is `MainActivity.kt:79`, which does not execute on the JVM. So the app's actual call — no arguments at all — is the one shape nothing exercises. ## This is not #68 #68 is about the two **unreachable** arms, `DarkColorScheme` and `LightColorScheme`, which cannot be reached because `dynamicColor` is always `true` and nothing can flip it. That is a product decision and it stays open. This ticket is the **reachable** half: whether the theme follows the system's dark-mode setting when asked with defaults. The two do not overlap, and closing this one does not close that one. ## The work Two `@Config(qualifiers = ...)` classes — `""` and `"+night"` — each calling `LibreMediaConverterTheme { }` bare and reading `MaterialTheme.colorScheme` from inside the content lambda, asserting the two differ in the direction the qualifier names (background luminance is the readable signal). This is the multi-`@Config` pattern `ForegroundTypeRegimeTest` established for the same reason: `app/src/test/resources/robolectric.properties` pins the suite to one configuration, so a per-class `@Config` is how a second regime gets exercised at all. Note that `#68`'s own text already recommends this shape ("Robolectric plus `createDrainedComposeRule()` can assert the resolved scheme differs across `darkTheme`/`dynamicColor`"), for the arms that survive whichever way #68 is decided. ## Acceptance: the mutation that must go red Change the default to `darkTheme: Boolean = false`. The `+night` test must fail. Restore, confirm green. ## Not in scope `Theme.kt:46`'s remaining `mb=4, cb=2` is Compose recomposition-skip scaffolding — the "do not chase the branch number" case `docs/coverage-read-findings.md` states for the screens. Leave it.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
above-cut
Worked autonomously overnight: local, JVM-verifiable, no product decision
 accessibility
Barrier affecting people with disabilities
 backlog
Held for manual review: product/UX call, CI/workflow, hardware, or unverifiable here
 bug
Something isn't working
 confirmed
Reviewer demonstrated the defect
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 plausible
Reviewer could not fully demonstrate it; treat as unproven
 question
Further information is requested
 sev:high
High severity
 sev:low
Low severity
 sev:medium
Medium severity
 wontfix
This will not be worked on
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
JMR-dev
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: JMR-dev/LibreMediaConverter#197