Jean-Luc Makiolaandmakiolaj
8b33635a85
Brings the branches the sibling apps actually ship from back onto main, so floret-kit stops forking per project. Merged in: - `vouch/settings` (what vouch pins), which already contains `feat/clockula` (what clockula pins) and `chore/deps-2026-10`: core-prefs, core-di, CollapsingScaffold FAB/no-back slots, the glance module, LocaleManager on API 33+, and the dependency bump - `feat/glance-module`: the three glance commits clockula's branch didn't have yet (progress ring/tile/check button, expressive shapes + header pill, WidgetDoneState) Both merged without conflicts. Version ends up at 0.7.0 (untagged). Heads-up for consumers: the deps bump moves the toolchain to Gradle 9.8.0 / AGP 9.4.1 / Kotlin 2.4.20. Since floret-kit is a composite build, a consumer must be on Gradle >= 9.6 to pin anything from here on. Calendula builds, tests and lints against this branch with just that toolchain bump, no source changes. Co-authored-by: Jean-Luc Makiola <business@jeanlucmakiola.de> Reviewed-on: https://codeberg.org/jlmakiola/floret-kit/pulls/11
1.5 KiB
1.5 KiB
floret-kit — documentation
floret-kit is the shared Material 3 Expressive design system + plumbing for
the Floret family of Android apps
(Calendula,
Agendula,
Clockula, and future
siblings). It is consumed from source as a git submodule + Gradle composite
build. See the top-level ../README.md for the pitch.
Index
| Doc | What it covers |
|---|---|
ARCHITECTURE.md |
How the kit is built and consumed — the module layering, JVM vs Android-library modules, the submodule + composite-build model, and the reproducibility rules. Start here. |
ROADMAP.md |
What's extracted, what's deferred, and what's deliberately not shared — the module status and the divergence decisions from the cross-app survey. |
../CONTRIBUTING.md |
The practical how — adding a module, the no-app-coupling rules, build/test, and how an app adopts the kit. |
../CHANGELOG.md |
Keep a Changelog; what each module added. |
The one principle
Share the mechanics, keep the look per-app.
Theme machinery, plumbing, and component primitives are shared; seed colours, palettes, identity chips, and app-specific wording stay in each app. This is what lets the family read as one design language without homogenising apps that are meant to have distinct personalities.