레퍼런스

위젯 레퍼런스

compose-rust 스키마의 위젯, Modifier, 역할 전부입니다. 스키마는 닫혀 있습니다. 렌더러는 정확히 이 목록만 해석하고 다른 것은 해석하지 않습니다. 모르는 위젯 종류를 받으면 충돌하지 않고 ProtocolError 이벤트를 냅니다.

위젯

이름은 Compose의 것입니다. 위젯마다 WidgetKind 에 고정된 태그가 있고, Kotlin 인터프리터에는 위젯마다 그리는 함수가 하나씩 있습니다.

Modifier

Compose에서 Modifier 는 어느 composable에나 붙고, 여기서도 같습니다. 모든 위젯이 모든 Modifier를 받으며, Text 와 Spacer 도 예외가 아닙니다. 와이어에서 Modifier 목록은 고정 크기 값의 나열이고, 렌더러가 이것을 Compose Modifier 체인으로 다시 만듭니다.

설정하지 않은 것은 0이 아닙니다. 쓰지 않은 Modifier는 아무것도 보내지 않습니다. 여백이 없는 것과 여백 0은 화면에서 같아 보이지만, 레코드 비용이 들어야 하는 것은 둘 중 하나뿐입니다.

역할 어휘

위젯은 리터럴이 아니라 역할을 내보냅니다. 역할은 일의 이름("강조색", "제목 단", "중간 모서리")이고, 렌더러가 활성 디자인 시스템에 맞춰 풉니다. 그래서 같은 트리가 어떤 기계에서는 Material 3로, 다른 기계에서는 Liquid Glass로 나옵니다. 시스템을 고르는 방법은 디자인 시스템에 있습니다. 아래 타입은 모두 0.0.1에 있습니다.

Paint와 Color

색을 받는 곳의 타입은 모두 Paint 입니다. 역할, 리터럴 ARGB 값, 또는 그라디언트 같은 등록된 브러시 중 하나입니다.

use compose_rust::{Color, ColorRole, Paint};

let accent = Paint::Role(ColorRole::Primary);          // resolved by the design system
let brand = Paint::Literal(Color::rgb(0x1b6ef3));     // opaque, 0xRRGGBB
let veil = Paint::Literal(Color::argb(0x80ff0000));    // 0xAARRGGBB

리터럴은 탈출구입니다. 디자인 시스템이 바뀌어도 그대로 남습니다. 브랜드 색처럼 그것이 바라는 바일 때도 있지만, 밝은 페이지에서 보이고 어두운 페이지에서 사라지는 색처럼 대개는 아닙니다. 브랜드 색에는 Palette 가 낫습니다. 앱 색을 보십시오.

ColorRole: 역할 45개

잉크를 가리키는 역할은 모두 그 잉크가 놓일 표면과 짝을 이룹니다. OnPrimary 는 Primary 로 채운 것 위의 잉크이고, 나머지도 같습니다.

패널이 페이지와 구별되어야 하면 SurfaceContainer 를 씁니다. Material 3는 일부러 Surface 와 Background 에 같은 값을 주고, 깊이는 톤이 다른 컨테이너로 나타냅니다. Background 페이지 위에 Surface 로 채운 패널은 맞는 색으로 그려지지만 보이지 않습니다. 지원하는 디자인 시스템은 모두 SurfaceContainer 를 페이지와 구별되게 만듭니다.

TypeRole: 아홉 단

ShapeRole, SpaceRole, MotionRole

ShapeRole 은 None, ExtraSmall, Small, Medium, Large, Full 입니다. 반지름은 디자인 시스템이 정하고, Full 은 캡슐 모양입니다.

SpaceRole 은 None, Xs, Sm, Md, Lg, Xl, Xxl 입니다. 밀도는 디자인 시스템마다 다르므로, 간격을 dp 숫자가 아니라 역할로 쓰는 것입니다.

MotionRole 은 Instant, Quick, Standard, Slow, Emphasized 입니다. 디자인 시스템마다 자기 길이와 곡선을 줍니다.

IconRole

아이콘은 플랫폼 아이콘 이름이 아니라 쓰임으로 고릅니다. Back, Forward, Close, Search, Add, Check, Settings, More, Home, List, Inbox, Menu, History 입니다. 역할이기 때문에 같은 선언이 Apple의 시스템에서는 SF Symbol로, Material 3에서는 Material Symbol로 나옵니다.

배치와 텍스트 열거형

창 크기

UI는 Rust가 기술하고 렌더러가 잽니다. 그래서 Rust가 창 너비를 아는 길은 렌더러가 알려 주는 것 하나뿐입니다. window_size() 는 width_dp, height_dp, class 와 is_compact(), is_medium(), is_expanded() 를 가진 WindowSize 를 돌려줍니다. 0.0.1에 있습니다.

클래스가 바뀔 때만 알립니다. 렌더러는 클래스가 바뀔 때 이벤트를 한 번 보내고 그 사이에는 아무것도 보내지 않습니다. 창을 700 dp에서 800 dp로 끌어도 Rust에서는 아무것도 깨어나지 않습니다. 레이아웃마다 바뀌는 크기를 알리면 레이아웃마다 Rust 코드가 돌기 때문입니다. 처음 재기 전에는 0 × 0의 Compact 입니다. 한 열 배치는 어느 너비에서나 쓸 수 있기 때문입니다.

Navigation, Sheet, Scaffold 는 렌더러가 이미 가진 노드를 옮겨서 스스로 적응합니다. 창 크기는 위젯이 대신 정해 줄 수 없는 결정, 예를 들어 한 열 대신 두 열로 놓는 데 씁니다.

위젯마다 상태를 두는 곳

애플리케이션 상태는 사용자의 것이고, UI 로컬 상태는 렌더러의 것입니다. 아래는 사람들이 놀라는 곳입니다. 제어되는 것처럼 보이는데 아니거나, 그 반대인 위젯입니다.

확장

확장은 컴파일 시점의 소스 파일 한 쌍, 곧 Rust 파일 하나와 Kotlin 파일 하나이고 두 쪽에 함께 빌드됩니다. 런타임 플러그인이 아닙니다. 배포된 렌더러는 새 위젯을 불러올 수 없습니다. 스키마 해시가 더는 맞지 않기 때문입니다. 크레이트에는 예제 하나, progress: f32 속성 하나를 가진 LinearProgressIndicator 가 있습니다.

직접 더하려면 compose-rust/src/extensions.rs 에 위젯과 속성 태그를 등록하고, 짝이 되는 Kotlin 렌더러에서 새 종류를 그립니다. 확장 위젯 태그는 100부터 시작하므로, 나중에 더해지는 핵심 위젯과 겹치지 않습니다.