0727a04bae
Artifacts, translations and projects each have a route, a state, a view model and a screen. A dialect had a `ListItem` inside `ChatRoomDetailScreen`'s `LazyColumn` with no `onClick`, which made it the one entity in a room a member could look at and not open. This is that screen, and the card finally gets the `onClick` it never had. The two lists are the reason it exists. A dialect is a name, a language code and a country; those three sit at the bottom under the details the way they do everywhere else, and what a member opens a dialect to find out is what the group has written in it. `MantraArtifact.dialectId` and `MantraTranslationArtifactVersion.dialectId` are the only two columns in the app that point at a dialect, and neither had a query. Both new queries are scoped by the dialect alone, with no `chatRoomId` beside it. `dialectId` is a foreign key into this room's own rows, so the key already confines the read to one room and a second filter would be a second spelling of a constraint that is already enforced. That is the one-room scope decision made load-bearing rather than restated; when a dialect can be named across rooms -- Phase 9 of docs/project-feature.md -- these two queries are among the places that have to learn about it, which is why the reasoning is on them rather than here. `Loaded` also carries `canAddSubgroup`, which Phase 3 needs and which is the same two conditions `ChatRoomDetailUIState` already states: a Marmot room, and a share of its key. It reads the room off the *dialect's* `chatRoomId` rather than the route's, so the parent of a subgroup made here is the room the dialect actually lives in even if a route is ever built by hand. A missing dialect is `Error` and not an empty `Loaded`, because "this room has written nothing in Sesotho" and "there is no such dialect here" would otherwise look identical and only one of them is worth a retry button. The test that earns its place is the two-dialects-in-one-room case: if either query ever drifted to scoping by room, every single-dialect test would still pass and that one would not. Phase 2 of docs/subgroups-for-entities.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This is a Kotlin Multiplatform project targeting Android, iOS, Desktop (JVM).
-
/composeApp is for code that will be shared across your Compose Multiplatform applications. It contains several subfolders:
- commonMain is for code that’s common for all targets.
- Other folders are for Kotlin code that will be compiled for only the platform indicated in the folder name. For example, if you want to use Apple’s CoreCrypto for the iOS part of your Kotlin app, the iosMain folder would be the right place for such calls. Similarly, if you want to edit the Desktop (JVM) specific part, the jvmMain folder is the appropriate location.
-
/iosApp contains iOS applications. Even if you’re sharing your UI with Compose Multiplatform, you need this entry point for your iOS app. This is also where you should add SwiftUI code for your project.
Build and Run Android Application
To build and run the development version of the Android app, use the run configuration from the run widget in your IDE’s toolbar or build it directly from the terminal:
- on macOS/Linux
./gradlew :composeApp:assembleDebug - on Windows
.\gradlew.bat :composeApp:assembleDebug
Build and Run Desktop (JVM) Application
To build and run the development version of the desktop app, use the run configuration from the run widget in your IDE’s toolbar or run it directly from the terminal:
- on macOS/Linux
./gradlew :composeApp:run - on Windows
.\gradlew.bat :composeApp:run
Build and Run iOS Application
To build and run the development version of the iOS app, use the run configuration from the run widget in your IDE’s toolbar or open the /iosApp directory in Xcode and run it from there.
Learn more about Kotlin Multiplatform…