|
|
| Line 1: |
Line 1: |
| =Declarative <span class="caps">QML</span>=
| |
|
| |
|
| It ''should'' be declarative. Let’s make the dream come true! What '''specific''', '''constructive''' changes can we make to help this happen without breaking everyone (and without making things impossible).
| |
|
| |
| Maybe just better
| |
|
| |
| ==Specific <span class="caps">API</span> issues==
| |
|
| |
| ===Changing State===
| |
|
| |
| StateChange element: like https://codereview.qt.io/#change,3356
| |
|
| |
| ===Loader/Repeater===
| |
|
| |
| It interrupts the hierarchy of objects, but main problem is that it’s getting abused.
| |
|
| |
| Deferred loading flag on Item would fix the not-really-dynamic case where they shouldn’t be using Loader. And tools can override the flag somehow.
| |
|
| |
| ===Signal Handlers===
| |
|
| |
| Pull model basically solves this in the cases where it’s abused.
| |
|
| |
| Could expose Polish, which might also solve it in specific cases.
| |
|
| |
| ===Translation===
| |
|
| |
| <span class="caps">DONE</span>! If it’s not in a complex expression of course.
| |
|
| |
| ==Strictly Declarative Mode==
| |
|
| |
| Of some interest, but needs more actual use-cases that it would solve before being worth the effort.
| |
|
| |
| ==Declarative Transactions (Atomic/Pull bindings)==
| |
|
| |
| Good idea. Tons and Tons of work.
| |