25 lines
1.5 KiB
Markdown
25 lines
1.5 KiB
Markdown
# Keluna development direction
|
|
|
|
Each development step should move the public Kotlin API closer to Vaadin Flow's
|
|
component model, as requested by the project owner. Prefer typed Component,
|
|
HasValue, value-change events and Binder APIs over exposing generic DOM elements
|
|
to application developers. Use familiar Vaadin names and semantics where practical,
|
|
with idiomatic Kotlin properties and lambdas. Keep the Element API as an escape
|
|
hatch and preserve existing examples. Keluna remains Kotlin/Native with a local
|
|
system WebView; this is API inspiration, not JVM/Vaadin binary compatibility.
|
|
|
|
New controls and bindings need native tests and browser bridge tests. Preserve
|
|
focus, caret position and IME composition during field synchronization. Validate
|
|
in Kotlin as well as rendering useful browser constraints. Document intentional
|
|
API limitations and verify desktop examples when changing the native adapter.
|
|
|
|
## Licensing
|
|
|
|
Keluna, including original examples and documentation, is Apache-2.0 licensed.
|
|
Keep LICENSE and NOTICE in distributions. Preserve existing third-party licenses
|
|
and notices; the project license does not override them. Before copying or porting
|
|
upstream code (including Vaadin examples), verify the exact file/version license
|
|
and follow docs/third-party-code.md. Record provenance and modifications, retain
|
|
required notices, and add applicable upstream NOTICE attributions. Do not assume
|
|
that commercial components or all documentation examples are Apache-2.0 licensed.
|