Feature/aurora build variant#387
Open
den3000 wants to merge 11 commits into
Open
Conversation
componentCoroutineScope was the only decompose/essenty user in shared:core's commonMain, and it kept decompose on tablet's compile classpath transitively. Decompose has no linux target, so it blocks the aurora variant. Its four consumers are all tv modules that already depend on :clients📺core:ui and declare decompose themselves. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
-PbuildVariant=aurora selects the whole plugin set at settings level: Compose fork 0.0.4-aurora plus aurora-build/aurora-devices, and a buildkonfig fork with linux targets. Fork artifacts resolve from a local maven folder given by auroraMavenPath in local.properties. Android/iOS and Aurora can never build in one invocation, so the aurora branch includes only the tablet modules and :clients:shared:core — backend/tv/smsrouter pull AGP and upstream Compose through build-logic. Each aurora module gets its own self-contained build file (linux targets, linuxMain, fork deps) instead of the build-logic convention plugins; upstream build files are untouched. The Compose plugin id is versionless everywhere so settings is the only place binding a version. The fork maven is repeated in the root allprojects block: project repositories take precedence over settings ones (PREFER_PROJECT), so declaring it only in settings leaves every fork artifact unresolved. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Napier publishes no linux targets and the fork ships no ui-tooling-preview for linux, so both packages are squatted by stub sources wired in only by the aurora build files. Call sites keep their imports. The napier stub lives in exactly one module — two modules declaring the same package would collide at klib link time — and reaches the tablet modules through shared:core's api dependency. The @Preview stub must declare widthDp/heightDp/ locale: feature/main passes them. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Curl engine for the ktor client, and the two small formatting/locale actuals. The settings store is in-memory for now (TODO in place): the fork ships ak-shared-preferences, but the port only needs to run first. toLocalisedString delegates to the existing common toFormattedString — linux has neither java.time nor NSDateFormatter, so month names stay English until the locale work. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The pickers drop to Material3 directly — that is what calf renders underneath on android anyway, so the colors carry over unchanged. TimeReceiver ticks on a coroutine (no broadcasts, no NSTimer on Aurora). Every tablet module now compiles for linuxX64 against the fork. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
composeApp becomes the linux binary under the aurora variant: aurora-build and aurora-devices replace com.android.application, and main() starts Koin then hands off to the shared AppRoot(). No root ViewModelStoreOwner needed here — AppRoot already provides one, unlike the reference where it sits at the entry point. Resources go through customDirectory pointing at core/ui, because aurora-build only packages its own module's prepared resources. Aurora flattens them to <qualifier>_<file>, which allows exactly one values_strings.commonMain.cvr — so the strings of feature/main, feature/settings and feature/bookingEditor will not resolve on device. Accepted for now; the fix is consolidating every tablet composeResources into core/ui behind a single Res. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
linkReleaseExecutableLinuxX64 dies with OutOfMemoryError on the default heap — the whole tablet graph links into one 59 MB binary. With this, the full pipeline (initSysroot > link > rpmbuild in Docker > sign) produces signed RPMs for aarch64 and x86_64. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The fork's components-resources renders SVG only under linux: handing it an Android Vector Drawable yields a blank screen with no crash, and all 20 tablet icons are vector XML. Call sites keep the canonical painterResource(Res.drawable.x) shape and only change the import; android/ios delegate to the native painter, while linux resolves the bytes itself and dispatches on the content signature — raster to BitmapPainter, <svg to Skia SVGDOM, otherwise vector XML to an ImageVector through the vendored AOSP-derived parser. Vectors keep Icon(tint) and intrinsic dp sizes. Parser and linux actual are ported from CorporateTaskTracker (same author), repackaged under core/ui. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…enames Two crashes on the first live run, both from the same fork limitation. 1. `vectorResource` in ExitButtonView/IconSuccess/FreeBookingButtonView called the fork's SVG-only loader and died with "Can't wrap nullptr". The painterResource polyfill picks up a sibling vectorResource actual; the three call sites switch to the local import, and android/ios keep delegating to the fork's own painter. 2. `stringResource` in ExitButtonView then died in Base64 decoding: Aurora packages compose resources flat under <qualifier>_<file> with no package namespace, so several modules' identically-named values/strings.xml turn into one values_strings.commonMain.cvr in the RPM — whichever module's Res gets there first reads someone else's .cvr at its own byte offsets. Fix: rename the per-module strings files to unique names (strings_app, strings_main, strings_settings, strings_booking_editor) and stage composeResources of every tablet module into one directory (stageAuroraResources) for customDirectory to hand aurora-build. Drawable filenames were already unique across modules. App now boots on the device, hits the local backend and renders the settings screen with the room picker. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Picking a room in Settings fires `navigate(MainRoute) { popUpTo<SettingsRoute> {
inclusive = true } }`. On Aurora the fork's navigation-compose logs
"Ignoring popBackStack to destination 0x… as it was not found on the current
back stack" and the whole builder aborts, so the screen never switches. The
reference project (CorporateTaskTracker) avoids `popUpTo<T>` entirely for the
same reason.
Pop by the graph's numeric startDestinationId instead — it doesn't go through
the reified type-safe resolver and works on all three variants.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…n screen
Picking a room navigated to MainRoute and the whole composition ran through
cleanly — every screen, panel and child emitted — yet the display kept showing
Settings. No crash, no log.
The cause was my own linux actual from an earlier commit: toLocalisedString
delegated to the common toFormattedString, which goes through kotlinx-datetime's
byUnicodePattern and rejects locale-dependent directives ("The directive 'MMMM'
is locale-dependent, but locales are not supported in Kotlin"). DateTimeView is
the first child of RoomInfoLeftPanel, so it threw on every frame — and the fork
swallows a throwing composable and silently rolls the frame back, which reads
exactly like "navigation didn't happen".
Expand the pattern by hand instead (d/M/y/H/h/m/s/a plus Russian month names).
Also clamp indexSelectRoom: it is -1 until the stored room appears in the list,
and roomList[-1] would take the main screen down the same way.
Note the popUpTo change in d168c49 was not the fix it claimed to be — the
warning it addresses is real but harmless. Comment corrected.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.