[Development] Improving QtQuick internals (was Re: QML engine changes)

[Alan Alpert]

On Wed, Jun 26, 2013 at 10:41 AM, Bubke Marco <Marco.Bubke at digia.com> wrote:
>
>[...]
>
> Better yet, join the discussion if you're interested. As an open
> project we do need to get better about having the design discussions
> in the open, and joining those discussions from the tooling side is
> encouraged. Then you aren't relying on other developers to be 'unsure'
> about something.
>
>
> Good to hear. So what is the plan for the "PropertyCache"?
Simon knows better than I, but I think the plan is for it to go away.

> What about a new better list interface(we have prototype here?
Sounds good! Where's the prototype so I can have a look?

> Maybe add signal compression instead of componentComplete.
It should remain as a fall-back, but once we have signal compression
we should consider rewriting all elements to avoid it (so that it's
just an imperative fall-back method and designer can ignore it).

> Always think about that you need a reverse transformation for direct
> manipulation(visual to text).
> Refactor the item code base.
>   Why do we have parent and parentItem?
Because we're layering another parent/child hierarchy onto QObject.
Now that we no longer have the QGraphicsItem implementation detail we
theoretically could unify them, but we still need to be able to
traverse the QQuickItem tree efficiently (and provide backwards
compatibility) and enforce a kind of 'tree-level type safety' where
QQuickItems are connected to the scene root through QQuickItems. I
haven't really thought about the possibility of unifying the trees
before, I'll have to give it some more thought.

>   Why do we mix the setParent and child list pattern?
In the declarative QML you should be using the child list in virtually
all cases. setParent is more there for imperative code, such as
creating an object in script (which ideally you'd be doing
declaratively through the Loader element.

--
Alan Alpert