docs: variants, bind_style if, transitions, easing

[kisvegabor]

No description provided.

[cubic-dev-ai]

1 issue found across 9 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="AGENTS.md">

<violation number="1" location="AGENTS.md:195">
P3: A non-subject `$prop` inside `@{ }` is described as "an error", which contradicts both this paragraph's own soft-failure theme and the authoritative docs/syntax/data-binding.mdx, where it is "skipped with a warning, but the widget is still created normally". Consider rewording to "skipped with a warning" so users don't expect a hard failure that doesn't occur.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: A non-subject $prop inside @{ } is described as "an error", which contradicts both this paragraph's own soft-failure theme and the authoritative docs/syntax/data-binding.mdx, where it is "skipped with a warning, but the widget is still created normally". Consider rewording to "skipped with a warning" so users don't expect a hard failure that doesn't occur.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At AGENTS.md, line 195:

<comment>A non-subject `$prop` inside `@{ }` is described as "an error", which contradicts both this paragraph's own soft-failure theme and the authoritative docs/syntax/data-binding.mdx, where it is "skipped with a warning, but the widget is still created normally". Consider rewording to "skipped with a warning" so users don't expect a hard failure that doesn't occur.</comment>

<file context>
@@ -161,15 +181,46 @@ Only `int`, `string` and `float` are supported.
 States: `default`, `checked`, `focused`, `focus_key`, `edited`, `hovered`, `pressed`, `scrolled`, `disabled`.
 Common flags: `hidden`, `clickable`, `checkable`, `scrollable`, `floating`, `ignore_layout`.
 
+`@{ }` is `{ }` that re-runs whenever a referenced subject or variant changes. It works on **widget** attributes (including `style_*` locals) and on a component instance's **variant** attributes. Not in `<styles>` (initialized once) and not on a component's own props or slots. It must reference at least one subject or variant, and inside it only `type="subject"` props may appear; other props are an error. A failed re-evaluation (e.g. `/0`) keeps the previous value.
+
+To give each instance its own data, declare `<prop name="temp" type="subject"/>` and pass a subject name at the call site: `<room_card temp="subject_kitchen"/>`.
</file context>

[cubic-dev-ai]

3 issues found across 6 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="docs/syntax/evaluate.mdx">

<violation number="1" location="docs/syntax/evaluate.mdx:40">
P3: Typo in the new `<bind_style if="...">` sentence: "There no `@{ }` wrapping is needed" should read "There's no ...". User-facing docs, so the grammar should be clean.</violation>
</file>

<file name="docs/syntax/data-binding.mdx">

<violation number="1" location="docs/syntax/data-binding.mdx:98">
P3: This example block is duplicated verbatim — the same `` comment and `<my_card tone="@{subject_alarm == 1 ? danger : normal}"/>` line appear twice in a row. Remove the redundant copy so readers don't see a confusing repeated sample.</violation>
</file>

<file name="docs/syntax/animations.mdx">

<violation number="1" location="docs/syntax/animations.mdx:112">
P3: This change rewrites the C-easing documentation to claim that an easing path is referenced directly by its function name (non-static, no registration, plain C function the generated file calls). That directly contradicts the same repo's AGENTS.md (docs/../AGENTS.md, Animations section), which still states: "easing ... or a callback registered with `lv_xml_register_easing_cb()`." It also silently removes the previously documented runtime path — the `lv_xml_register_easing_cb(NULL, "my_easing", my_easing);` call and the note that the name is resolved while XML is being parsed and must be registered before use. Because both documents ship in this PR series, one of them is now stale, and a reader relying on either will get contradictory instructions (especially for runtime XML loading vs. exported code). Please reconcile the two documents so they describe the same mechanism — if the implementation still requires `lv_xml_register_easing_cb()` for any loading path, keep that guidance; if easing is now always resolved by symbol/function name, update AGENTS.md to match.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: Typo in the new <bind_style if="..."> sentence: "There no @{ } wrapping is needed" should read "There's no ...". User-facing docs, so the grammar should be clean.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At docs/syntax/evaluate.mdx, line 40:

<comment>Typo in the new `<bind_style if="...">` sentence: "There no `@{ }` wrapping is needed" should read "There's no ...". User-facing docs, so the grammar should be clean.</comment>

<file context>
@@ -7,44 +7,59 @@ description: Compute attribute values from arithmetic, comparisons, ternaries, a
 </Callout>
 
-## Writing expressions
+The same expression engine is used in `<bind_style if="...">` too. There no `@{ }` wrapping is needed, as that attribute is always treated as a binding.
 
-An expression is the whole attribute value, wrapped in a single pair of braces:
</file context>

Suggested change

	The same expression engine is used in `<bind_style if="...">` too. There no `@{ }` wrapping is needed, as that attribute is always treated as a binding.
	The same expression engine is used in `<bind_style if="...">` too. There's no `@{ }` wrapping needed, as that attribute is always treated as a binding.

[cubic-dev-ai]

P3: This example block is duplicated verbatim — the same <!-- ✅ tone is a variant of my_card --> comment and <my_card tone="@{subject_alarm == 1 ? danger : normal}"/> line appear twice in a row. Remove the redundant copy so readers don't see a confusing repeated sample.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At docs/syntax/data-binding.mdx, line 98:

<comment>This example block is duplicated verbatim — the same `<!-- ✅ `tone` is a variant of my_card -->` comment and `<my_card tone="@{subject_alarm == 1 ? danger : normal}"/>` line appear twice in a row. Remove the redundant copy so readers don't see a confusing repeated sample.</comment>

<file context>
@@ -55,150 +58,59 @@ value. Integer, string, and float types are supported.
+<my_card title="@{subject_user_name}"/>
 
-`@{ }` and `{ }` share the same syntax, operators, and type rules, see [Evaluate expressions](./evaluate). The difference is only *when* they run:
+<!-- ✅ `tone` is a variant of my_card -->
+<my_card tone="@{subject_alarm == 1 ? danger : normal}"/>
 
</file context>

[cubic-dev-ai]

P3: This change rewrites the C-easing documentation to claim that an easing path is referenced directly by its function name (non-static, no registration, plain C function the generated file calls). That directly contradicts the same repo's AGENTS.md (docs/../AGENTS.md, Animations section), which still states: "easing ... or a callback registered with lv_xml_register_easing_cb()." It also silently removes the previously documented runtime path — the lv_xml_register_easing_cb(NULL, "my_easing", my_easing); call and the note that the name is resolved while XML is being parsed and must be registered before use. Because both documents ship in this PR series, one of them is now stale, and a reader relying on either will get contradictory instructions (especially for runtime XML loading vs. exported code). Please reconcile the two documents so they describe the same mechanism — if the implementation still requires lv_xml_register_easing_cb() for any loading path, keep that guidance; if easing is now always resolved by symbol/function name, update AGENTS.md to match.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At docs/syntax/animations.mdx, line 112:

<comment>This change rewrites the C-easing documentation to claim that an easing path is referenced directly by its function name (non-static, no registration, plain C function the generated file calls). That directly contradicts the same repo's AGENTS.md (docs/../AGENTS.md, Animations section), which still states: "easing ... or a callback registered with `lv_xml_register_easing_cb()`." It also silently removes the previously documented runtime path — the `lv_xml_register_easing_cb(NULL, "my_easing", my_easing);` call and the note that the name is resolved while XML is being parsed and must be registered before use. Because both documents ship in this PR series, one of them is now stale, and a reader relying on either will get contradictory instructions (especially for runtime XML loading vs. exported code). Please reconcile the two documents so they describe the same mechanism — if the implementation still requires `lv_xml_register_easing_cb()` for any loading path, keep that guidance; if easing is now always resolved by symbol/function name, update AGENTS.md to match.</comment>

<file context>
@@ -95,26 +95,21 @@ For full control, `bezier(x1 y1 x2 y2)` describes a cubic bezier curve with its

-Register the callback before the XML that uses it, as the name is resolved while the XML is being parsed. In the exported code the name is emitted as a plain C function reference, so the function has to be visible to the generated file.
+The exported code calls this function directly, so it can't be static and it has to be visible where the generated file is compiled.

Include External Timelines

</file context>

</details>

[cubic-dev-ai]

1 issue found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="docs/syntax/data-binding.mdx">

<violation number="1" location="docs/syntax/data-binding.mdx:103">
P2: This new example contradicts the rules stated a few lines above it in the same file. The doc explains that `@{ }` cannot be used on a Component instance's own props (the `<my_card title="@{subject_user_name}"/>` line is marked ❌ for exactly this reason), yet the added `h3` example binds `@{}` to `text`, which `h3` declares as a plain `type="string"` Component prop (see templates/basic/components/typography/h3/h3.xml). That makes `text` a component prop analogous to `my_card`'s `title`, not an lv_label widget attribute that becomes bindable on the instance — the comment's justification doesn't hold. If the intent is that `h3` really does support binding its `text`, this needs the rule/❌ example updated too; otherwise the example should be removed or reworked (e.g. show binding inside the component's `<view>`, or to a `type="subject"` prop) so the docs stay internally consistent.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: This new example contradicts the rules stated a few lines above it in the same file. The doc explains that @{ } cannot be used on a Component instance's own props (the <my_card title="@{subject_user_name}"/> line is marked ❌ for exactly this reason), yet the added h3 example binds @{} to text, which h3 declares as a plain type="string" Component prop (see templates/basic/components/typography/h3/h3.xml). That makes text a component prop analogous to my_card's title, not an lv_label widget attribute that becomes bindable on the instance — the comment's justification doesn't hold. If the intent is that h3 really does support binding its text, this needs the rule/❌ example updated too; otherwise the example should be removed or reworked (e.g. show binding inside the component's <view>, or to a type="subject" prop) so the docs stay internally consistent.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At docs/syntax/data-binding.mdx, line 103:

<comment>This new example contradicts the rules stated a few lines above it in the same file. The doc explains that `@{ }` cannot be used on a Component instance's own props (the `<my_card title="@{subject_user_name}"/>` line is marked ❌ for exactly this reason), yet the added `h3` example binds `@{}` to `text`, which `h3` declares as a plain `type="string"` Component prop (see templates/basic/components/typography/h3/h3.xml). That makes `text` a component prop analogous to `my_card`'s `title`, not an lv_label widget attribute that becomes bindable on the instance — the comment's justification doesn't hold. If the intent is that `h3` really does support binding its `text`, this needs the rule/❌ example updated too; otherwise the example should be removed or reworked (e.g. show binding inside the component's `<view>`, or to a `type="subject"` prop) so the docs stay internally consistent.</comment>

<file context>
@@ -95,6 +95,13 @@ It can't be used in the `<styles>` section, as [styles](./styles) are initialize
+
+<!-- ✅ `text` comes from `lv_label` that `h3` extends. 
+     It means a binding can be used on it.-->
+<h3 text="@{'Hi ' . subject_name}"/>
+
 <!-- ✅ `tone` is a variant of my_card -->
</file context>

[cubic-dev-ai]

2 issues found across 12 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="docs/syntax/components.mdx">

<violation number="1" location="docs/syntax/components.mdx:102">
P3: The prose on line 92 still says API properties are referenced "using `$`", but the examples in this same section (and the api.mdx reference) now use `{btn_text}`. Update the wording to reference `{ }` so the section doesn't contradict its own examples and the linked API docs.</violation>
</file>

<file name="docs/syntax/styles.mdx">

<violation number="1" location="docs/syntax/styles.mdx:242">
P3: This new example uses the modern `{ }`/`<consts>` syntax (`<consts><int name="thin"/></consts>` and `border_width="{thin * 2}"`), but the "Relation to Constants" section directly above on the same page still documents the legacy form: `<constants>` tag with `border_width="#thin" bg_color="#dark"`. The change modernizes API `<prop>` references from `$` to `{}` yet leaves the adjacent constants section in the old `#`/`<constants>` style, so the page now teaches two conflicting constant conventions. Consider updating that section to `<consts>` + `{ }` to match.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: The prose on line 92 still says API properties are referenced "using $", but the examples in this same section (and the api.mdx reference) now use {btn_text}. Update the wording to reference { } so the section doesn't contradict its own examples and the linked API docs.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At docs/syntax/components.mdx, line 102:

<comment>The prose on line 92 still says API properties are referenced "using `$`", but the examples in this same section (and the api.mdx reference) now use `{btn_text}`. Update the wording to reference `{ }` so the section doesn't contradict its own examples and the linked API docs.</comment>

<file context>
@@ -99,7 +99,7 @@ However, you can also define custom properties in the [`api` tag](./api). These
 
   <view extends="lv_button">
-    <lv_label text="$btn_text"/>
+    <lv_label text="{btn_text}"/>
   </view>
 </component>
</file context>

[cubic-dev-ai]

P3: This new example uses the modern { }/<consts> syntax (<consts><int name="thin"/></consts> and border_width="{thin * 2}"), but the "Relation to Constants" section directly above on the same page still documents the legacy form: <constants> tag with border_width="#thin" bg_color="#dark". The change modernizes API <prop> references from $ to {} yet leaves the adjacent constants section in the old #/<constants> style, so the page now teaches two conflicting constant conventions. Consider updating that section to <consts> + { } to match.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At docs/syntax/styles.mdx, line 242:

<comment>This new example uses the modern `{ }`/`<consts>` syntax (`<consts><int name="thin"/></consts>` and `border_width="{thin * 2}"`), but the "Relation to Constants" section directly above on the same page still documents the legacy form: `<constants>` tag with `border_width="#thin" bg_color="#dark"`. The change modernizes API `<prop>` references from `$` to `{}` yet leaves the adjacent constants section in the old `#`/`<constants>` style, so the page now teaches two conflicting constant conventions. Consider updating that section to `<consts>` + `{ }` to match.</comment>

<file context>
@@ -222,14 +222,28 @@ Since styles are initialized only once, it's not possible to pass API properties
+
+<styles>
+    <!-- ✅ Constants and literals work -->
+    <style name="style_main" border_width="{thin * 2}"/>
+</styles>
+```
</file context>

[cubic-dev-ai]

1 issue found across 12 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="docs/syntax/evaluate.mdx">

<violation number="1" location="docs/syntax/evaluate.mdx:116">
P3: The lead-in "A property, subject or variant has no value at that point" is imprecise for subjects: a subject always holds a value (its initial value from globals.xml), so it does "have a value" at registration — it simply can't be referenced by these one-time sections. The explanation that follows ("a subject or variant would have to be read again later") is the accurate rationale, and the 'has no value' summary contradicts it and could mislead readers who know subjects carry values.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: The lead-in "A property, subject or variant has no value at that point" is imprecise for subjects: a subject always holds a value (its initial value from globals.xml), so it does "have a value" at registration — it simply can't be referenced by these one-time sections. The explanation that follows ("a subject or variant would have to be read again later") is the accurate rationale, and the 'has no value' summary contradicts it and could mislead readers who know subjects carry values.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At docs/syntax/evaluate.mdx, line 116:

<comment>The lead-in "A property, subject or variant has no value at that point" is imprecise for subjects: a subject always holds a value (its initial value from globals.xml), so it does "have a value" at registration — it simply can't be referenced by these one-time sections. The explanation that follows ("a subject or variant would have to be read again later") is the accurate rationale, and the 'has no value' summary contradicts it and could mislead readers who know subjects carry values.</comment>

<file context>
@@ -81,6 +81,42 @@ Names are written as **bare identifiers**, without the `$` or `#` prefixes used
+</animations>
+```
+
+A **property**, **subject** or **variant** has no value at that point: a property has no instance to take it from, and a subject or variant would have to be read again later, which these sections can't do. Using one is reported.
+
+An `if_target` block is filtered before its content is processed, so an expression there sees the constants of the current target.
</file context>

Suggested change

	A **property**, **subject** or **variant** has no value at that point: a property has no instance to take it from, and a subject or variant would have to be read again later, which these sections can't do. Using one is reported.
	A **property** has no instance to take a value from, and a **subject** or **variant** would have to be read again later, which these sections can't do. Using one is reported.