Open hanthor opened 4 months ago
Nice, you found ScPrefs :+1:
One of the most important aspects for SchildiChat these days is keeping code easily maintainable in a long term, while avoiding upstream merge conflicts as much as possible. So your changes to ColorAliases.kt
would in the current state be a blocker.
ScColorAliasesExtensions.kt
in the same package, so they can easily be used the same way while not having to touch the upstream file.get() = scOverride() ?: if (isLight) ...
such that you only add scFunction() ?:
in front of Element code. Then you can define the sc function in ScColorAliasesExtensions.kt
, and make it return null for the cases we do not need/want to modify such that it falls back to upstream code just in that case. Similar to https://github.com/SchildiChat/schildichat-android-next/commit/9b712b4e41056e280755429dc791fb231fed038b where I don't use a function but an exposed value directly, but I guess you need a function here.More precisely, I could imagine it something like this (untested code, may need some modifications): Your code:
val SemanticColors.pinDigitBg
get() = if (isLight) {
@Composable
get() = if (DynamicColorPreferences.isDynamicColorEnabled) {
colorScheme.onPrimaryContainer
} else if (isLight) {
Color(0xFFF0F2F5)
} else {
Color(0xFF26282D)
gets into
val SemanticColors.pinDigitBg
get() = scSemColorOverride(colorScheme.onPrimaryContainer) ?: if (isLight) {
// We want LightDesignTokens.colorGray300
Color(0xFFF0F2F5)
} else {
// We want DarkDesignTokens.colorGray400
Color(0xFF26282D)
}
where only scSemColorOverride(colorScheme.onPrimaryContainer) ?:
was inserted, rest is still upstream,
with
@Composable
fun scSemColorOverride(dynamicThemeColor: Color) = dynamicThemeColor.takeIf { DynamicColorPreferences.isDynamicColorEnabled }
in an SC-owned file.
Wow, cool PR.
I hope you will add later (lets release this fast) the pureblack option. Is it possible to take that option from the Distro? (LineageOS, CalyxOS and so on).