v0.2.23
qml4j 0.2.23
Fix: a colour-hex string keeps its String methods in JS
A Java String that happens to match a hex-colour pattern (e.g. "#ff33aa55") is wrapped as
JsColor when it crosses into JS. JsColor previously exposed only .r/.g/.b/.a and returned
NOT_FOUND for every other member, so any ordinary string op on it -- charAt, substring,
indexOf, length, ... -- was undefined. Calling one inside a compiled QML function body
silently aborted the rest of the function with no exception, making the failure invisible
(a colour picker seeding HSV from a "#aarrggbb" model value would just do nothing).
JsColor now falls back to the underlying hex String's String.prototype members (named and
indexed) for anything that isn't an r/g/b/a channel, so a colour-hex value behaves as both
a colour (channels) and a string (methods/length). "#ff33aa55".charAt(0) === "#",
.length === 9, etc. No app-side "" + hex coercion needed anymore.
Also
- Removed the unused
QmlView.pumpLayouttest hook (its callers went with the incremental
layout removed in 0.2.22).
Compatibility
No API breakage. New test JsColorStringMethodTest; 604 tests green.
Full Changelog: v0.2.22...v0.2.23