1.5 KiB
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.