three wrapping columns on a picker page, in the order the locale writes a date
mounted as date-picker
why it looks like this
The date picker the phone navigated to: a page of tall square columns, one per component of the date, tipping in from -50°.
This is KvadrantLoopingSelector and KvadrantPickerPage assembled — both were built, tested and previewed long before the thing they are halves of existed, which is what B-42 was about. The metrics are all in the selector: 148 × 148 px cells, the number at 54 px.
The columns wrap, which is what makes the selector "looping". Each shows visibleCount values centred on the current one, and the neighbours are the values on either side modulo the range — so the cell after 31 December is 1 December rather than nothing. Tapping a neighbour moves the selection by that much.
The day clamps when the month changes, because 31 January has no February. Moving from a long month to a short one lands on the last day of the short one, which is what every picker that offers a day column has to do and the reason this component needs daysInMonth at all.
Month names are the caller's. A component library cannot ship two hundred locales' month abbreviations, and shipping one locale's would be a language decision made by a picker. With monthNames left null the column shows the month's number, which is what a short date does in most of the world anyway.
order | defaults to KvadrantDateOrder.forLocale, which is a table — read its documentation before relying on it for a locale that matters. |
years | the range the year column moves within. Wrapping applies here too, so a hundred years either side is a range and not a limit anybody meets. |
Read it: kvadrant-core/src/commonMain/kotlin/io/github/youndie/kvadrant/components/KvadrantDateTimePicker.kt · the full signature and every parameter