07/08/2019, 10:54 AM
Dear Android Compose Team, please do not re-use the existing style system Android provides, its a PITA to use right, memorize, extend and embrace. Please come up with something better, that doesn't force you to read and distribute base style information across dozens of files. Thank you! - A plagued user.
👍 16
☝️ 6


07/08/2019, 11:27 AM
Yes, we're radically simplifying styles. I think you'll like it much better (basically, just uses standard Kotlin code to create/specify styles). Still a work in progress, but you can take a look at the material widgets/samples defined in Compose for an early preview.
💯 25


07/08/2019, 1:00 PM
@jim hello. maybe you have some links to samples of material widgets from preview?


07/08/2019, 3:59 PM
How would you make sure that the new style system and the existing one stayed in sync?
☝️ 1
👋 1

Adam Powell

07/08/2019, 6:57 PM
So far, by only doing it one way. We can consume the existing styles for use in a compose sub-hierarchy but since compose styles are dynamic we can't do the same in the other direction; we don't have the compiled resource table entries for the existing code to consume
We can pass through, but we can't update unless the developer gives us an explicit (static) theme id when switching back to views


07/08/2019, 7:26 PM
hopefully it’ll be some sort of non-static typed map<attribute, value> with clear override/composition api

Adam Powell

07/08/2019, 8:19 PM
the current thinking is very much static typed, the grab bag style has been a source of a lot of the confusion and frustration with the current system. Definite yes to clear override/composition API.
Rather than extending themes and styles by adding arbitrary properties to one collection, we're looking at several separate use case and design system driven Ambient (think tree-local) values that can be overridden and replaced for a given subtree. e.g. theme colors, typography, and shapes when it comes to material widgets.
and you can define your own Ambients when desired if you want to add new things with similar cascading characteristics
we're looking at putting drastically fewer things into theme-like constructs like this, no such things as default widget styles referenced from a theme, etc.
👍 4
and the things that do go in there are not meant to be widget-specific, rather they're general things that many widgets are meant to appeal to


07/08/2019, 8:26 PM
sounds promising 👍 I’m sure you’re on top of it, but just wanted to list few obvious use-cases: - Developer(s) slightly modifying default theme (read “Material”) - Teams building default theme-based design system for their app - Teams building totally custom design system for their app There is also multi-platform component to it, but nailing Android-specific API is a great start

Adam Powell

07/08/2019, 8:26 PM
Yep, those three cases are all top of mind


07/08/2019, 8:26 PM
To the last point “not meant to be widget-specific”, not sure how this will play with type-safety you’re looking for heh

Adam Powell

07/08/2019, 8:28 PM
for example, a material raised button won't read a default raised button style and its background color from that, instead it will read the current material colors, take the primary color, and apply it to its background. (Assuming no explicit color was provided to the use-site of the button widget.)
so for material widgets the theme-ambients will map pretty directly to the material design spec:
and other design systems can use the same tools (Ambients, related patterns) to implement theming that makes sense for those design systems
rather than trying to create some platonic ideal of a theming system that tries to cover absolutely everything and then ends up needing arbitrary property maps
👍 4


07/11/2019, 4:04 PM
Please, I would like to have CSS for styling on Android.
🚫 9
😣 1
😿 1