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

[Alan Alpert]

On Wed, Jun 26, 2013 at 11:50 AM, Knoll Lars <Lars.Knoll at digia.com> wrote:
> On 6/26/13 8:04 PM, "Alan Alpert" <416365416c at gmail.com> wrote:
>
>>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.
>
> Yes, as much as possible, but I'm not sure how fast we can make it happen.
> I'm actually looking into related things right now. But first I need to
> clean up the QStringHash and related classes.
>
>>> 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).
>
> Yes, I'd agree to this as well.
>>
>>> 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.
>
> I hope that's going to be possible, but I don't think anybody tried yet ;-)
>
>
>>>   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.
>
> It might also be required for some performance optimisations where I'd
> like to create a subtree in a secondary thread and then hook it into the
> main QML tree once it's created. But that's certainly 5.3 material :)

That's not a prerequisite. Any trees in QML are either going to be
using the child list or will be imperatively loaded later as a
separate subtree (which could also be easily moved to another thread).
Even if you do
Item {
    id: root
    Item {
        id: theParent
    }
    Item {
       id: theChild
       parent: theParent
    }
}
(which I have never seen, and might not work) you assigned it to a
child list and then re-assigned it, so it was already objectively bad
QML. Otherwise you're imperatively loading it.

--
Alan Alpert