Open rfc2822 opened 1 month ago
These themes reflect our current color scheme in M3:
material-theme-classic.zip material-theme-classic-reversed.zip
We should also follow the recommended App Architecture more when refactoring. Like having more clear and separated UI state holders, using Compose state in ViewModels etc.
Now we don't have FABs or other accent elements yet but I also like the "reversed" theme more:
I've read a bit more into the color scheming of M3 and it seems unless we want to define everything (!) on our own we can't use our brand color green (with orange in addition) anymore.
I've adapted our colors a bit and here is an updated version for now that looks more appealing:
material-theme-moreappealing.zip
It now looks like this:
I've read a bit more into the color scheming of M3 and it seems unless we want to define everything (!) on our own we can't use our brand color green (with orange in addition) anymore. [...] It now looks like this:
Well, this definetly makes for a better integration with jtxBoard. They look the same now :clinking_glasses:
I've read a bit more into the color scheming of M3 and it seems unless we want to define everything (!) on our own we can't use our brand color green (with orange in addition) anymore. [...] It now looks like this:
Well, this definetly makes for a better integration with jtxBoard. They look the same now 🥂
but we're still green, while jtx is yellow :P wooow
Time to have fun
https://developer.android.com/develop/ui/compose/designsystems/material2-material3#phased-approach
This is a meta-issue and can be closed when everything is M3. Please don't add things here yourself.
When rewriting things to M3, please apply the new App Architecture as discussed as well as it's possible without rewriting core features (for instance, I wouldn't touch data layer things too much during the rewrite):
SomeScreen.kt
with the@Composable SomeScreen()
(only UI, no or little UI logic)SomeScreenModel.kt
with the ViewModel for SomeScreen (UI logic and interface to data layers, if required); usually contains a UI state data class + methods to calculate state for the UI + methods for events that come from the UISomeActivity.kt
with the Activity (if the screen is an Activity) – should only contain the contractUiState
classes as described in App Architecture. One explicit UI state data class +mutableStateOf(UiState()) private set
in the model is preferred, but you may have to use Flows or other methods like multiple states if it fits better.Tasks: